View a markdown version of this page

Utilisation de contraintes de clé étrangère dans Aurora DSQL - Amazon Aurora DSQL

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Utilisation de contraintes de clé étrangère dans Aurora DSQL

Les contraintes de clé étrangère d'Aurora DSQL vous permettent d'intégrer la logique d'intégrité référentielle d'une application dans la base de données. Aurora SQL prend en charge les NO ACTION actionsRESTRICT,CASCADE,SET NULL, et SET DEFAULT référentielles. Il prend également en charge les types MATCH FULL et MATCH SIMPLE match, ainsi que les contraintes de clé étrangère différées. Pour une description complète de la syntaxe, consultezContraintes liées aux clés étrangères.

Comment Aurora DSQL préserve l'intégrité référentielle

Aurora DSQL préserve l'intégrité référentielle en deux étapes : la vérification des instantanés lors de l'exécution de la transaction et la résolution des conflits au moment de la validation. Ensemble, ces étapes garantissent qu'une transaction validée ne viole jamais une contrainte de clé étrangère.

Vérification des instantanés. Chaque transaction dans Aurora DSQL est exécutée en fonction d'un instantané cohérent de la base de données pris au moment de son démarrage. Lorsque vous insérez ou mettez à jour une ligne de référence, Aurora DSQL lit la table référencée sur l'instantané de début de votre transaction pour confirmer l'existence de la clé référencée. Lorsque vous supprimez ou mettez à jour une clé référencée, Aurora DSQL lit la table de référence dans l'instantané de transaction. Cela confirme qu'aucune ligne de référence n'existe (pourRESTRICT) ou que l'opération ne laisse aucune ligne orpheline (pourNO ACTION). Comme cette vérification lit à partir de l'instantané de début de la transaction au lieu de le verrouiller, les autres transactions peuvent continuer à modifier les tables référencées et de référence en parallèle.

Commit-time résolution. La vérification instantanée garantit que la contrainte est maintenue à l'heure de début de la transaction, mais pas entre le début et la validation. Une transaction simultanée peut supprimer la ligne référencée ou insérer une ligne de référence en conflit après le début de votre transaction. Pour résoudre ces conflits, Aurora DSQL applique implicitement la KEY SHARE clause aux lignes référencées afin de détecter si une modification simultanée a invalidé votre instantané. Si Aurora DSQL détecte un conflit, la transaction échoue avec une erreur de sérialisation. Pour plus d'informations sur la manière dont la KEY SHARE clause affecte les transactions simultanées, consultezContrôle de simultanéité dans Aurora DSQL.

Les contrôles d'intégrité référentielle entraînent des lectures supplémentaires

Toutes les opérations du langage de manipulation de données (DML) sur les tables référencées ou de référence entraînent des lectures supplémentaires pour garantir l'intégrité référentielle. Avant d'ajouter une contrainte de clé étrangère à un tableau, comparez la charge de travail et vérifiez que les caractéristiques de performance répondent à vos attentes.

Exemples de scénarios

Dans le scénario suivant, la product_id colonne de la orders table qui fait référence à la products table comporte une contrainte de clé étrangère. Cela crée products la table référencée et orders la table de référence.

CREATE TABLE products ( product_id integer PRIMARY KEY, name text, price numeric ); CREATE TABLE orders ( order_id integer PRIMARY KEY, product_id integer REFERENCES products, quantity integer ); INSERT INTO products VALUES (1, 'Widget', 9.99);

Conflit : suppression et insertion simultanées

Dans ce scénario, une session supprime une ligne référencée tandis qu'une autre session insère une ligne de référence.

-- Session A BEGIN; DELETE FROM products WHERE product_id = 1; -- Session B BEGIN; INSERT INTO orders VALUES (100, 1, 5); -- Session A COMMIT; -- succeeds -- Session B COMMIT; -- fails with serialization error ERROR: change conflicts with another transaction (OC000) (SQLSTATE 40001)

Les deux sessions se déroulent en même temps. Aurora DSQL résout le conflit lors de la validation. Vous ne pouvez pas vous retrouver avec une commande qui pointe vers un produit supprimé.

Aucun conflit : mise à jour des colonnes non clés

Dans ce scénario, une session met à jour une colonne non clé sur la ligne référencée tandis qu'une autre session insère une ligne de référence.

-- Session A BEGIN; UPDATE products SET name = 'Super Widget' WHERE product_id = 1; -- Session B BEGIN; INSERT INTO orders VALUES (101, 1, 3); -- Session A COMMIT; -- succeeds -- Session B COMMIT; -- succeeds

La mise à jour name (une colonne non clé) n'entre pas en conflit avec la clé étrangère activéeproduct_id. La ligne de référence veille uniquement à ce que les colonnes clés de la ligne référencée restent les mêmes.

Meilleures pratiques en matière de clés étrangères dans Aurora DSQL

Implémenter une logique de nouvelle tentative

Les conflits sont à l'origine d'erreurs et non d'attentes. Concevez votre charge de travail de manière à réessayer les transactions ayant échoué. Pour plus d'informations sur la simultanéité dans Aurora DSQL, consultez. Contrôle de simultanéité dans Aurora DSQL

Minimiser le taux de rotation des colonnes clés sur les lignes fortement référencées

Si plusieurs lignes de référence font référence à la même ligne et que ses colonnes clés changent souvent, envisagez de restructurer le schéma. Déplacez les valeurs qui changent fréquemment vers des colonnes non clés afin que la colonne référencée reste stable. La modification de colonnes non clés dans la table référencée n'entre pas en conflit avec le référencement des inserts.