Comment fonctionnent les options «on update» et «on delete» de la clé étrangère Postgres?

Question

Quelqu'un peut-il fournir une explication / un exemple clair de ce que font ces fonctions et du moment approprié pour les utiliser?

Answer 1

Directement de le manuel ...

  

Nous savons que les clés étrangères interdisent la création de commandes qui ne concernent aucun produit. Mais que se passe-t-il si un produit est supprimé après la création d'une commande qui le référence? SQL vous permet de gérer cela aussi. Intuitivement, nous avons quelques options:

     

Interdire la suppression d'un produit référencé

     

Supprimez également les commandes

     

Autre chose?

CREATE TABLE order_items (
 product_no integer REFERENCES products ON DELETE RESTRICT,
 order_id integer REFERENCES orders ON DELETE CASCADE,
 quantity integer,
 PRIMARY KEY (product_no, order_id)
);

  

La restriction et les suppressions en cascade sont les deux options les plus courantes. RESTRICT empêche la suppression d'une ligne référencée. NO ACTION signifie que s'il reste des lignes de référence lors du contrôle de la contrainte, une erreur est générée. C'est le comportement par défaut si vous ne spécifiez rien. (La différence essentielle entre ces deux choix est que NO ACTION permet de différer la vérification plus tard dans la transaction, contrairement à RESTRICT.) CASCADE spécifie que, lorsqu'une ligne référencée est supprimée, la ou les lignes qui le référencent doivent être automatiquement supprimées. ainsi que. Il existe deux autres options: SET NULL et SET DEFAULT. Cela a pour effet de définir les colonnes de référence sur NULL ou sur les valeurs par défaut, respectivement, lorsque la ligne référencée est supprimée. Notez que cela ne vous dispense pas d'observer des contraintes. Par exemple, si une action spécifie SET DEFAULT mais que la valeur par défaut ne satisferait pas la clé étrangère, l'opération échouera.

     

Analogue à ON DELETE, il existe également ON UPDATE qui est invoqué lorsqu’une colonne référencée est modifiée (mise à jour). Les actions possibles sont les mêmes.

modifier: Vous voudrez peut-être examiner cette question connexe: Quand / Pourquoi utiliser la mise en cascade dans SQL Server? . Les concepts derrière la question / les réponses sont les mêmes.

Answer 2

J'ai une base de données PostGreSQL et j'utilise On Delete lorsque j'ai un utilisateur que je supprime de la base de données et que je dois supprimer ses informations d'une autre table. De cette façon, je n'ai besoin que d'une suppression et FK qui a ON supprime les informations d'un autre tableau.

Vous pouvez faire la même chose avec ON Update. Si vous mettez à jour la table et que le champ a un FK avec On Update, si une modification est apportée sur le FK, vous serez remarqué sur la table FK.

Answer 3

Ce que Daok dit est vrai ... cela peut être assez pratique. D'autre part, le fait que les choses se passent automatiquement dans la base de données peut être un réel problème, en particulier lorsqu'il s'agit d'éliminer des données. Il est possible qu'à l'avenir quelqu'un compte sur le fait que les FK empêchent généralement la suppression des parents lorsqu'il y a des enfants et ne réalisent pas que votre utilisation de On Delete Cascade n'empêche pas la suppression, elle génère d'énormes quantités de données dans des dizaines de les autres tables disparaissent grâce à une cascade de suppressions en cascade.

Le commentaire d'Arthur.

Plus fréquemment " masqué " Les choses se passent dans la base de données, moins il est probable que quiconque aura une bonne idée de ce qui se passe. Les déclencheurs (et il s’agit essentiellement d’un déclencheur) peuvent entraîner ma simple action de supprimer une ligne, ce qui a de lourdes conséquences sur l’ensemble de ma base de données. J'émets une instruction Delete et 17 tables sont affectées par des cascades de déclencheurs et de contraintes, et rien de tout cela n'apparaît immédiatement pour l'émetteur de la commande. OTOH, si je place la suppression du parent et de tous ses enfants dans une procédure, il est très facile et clair pour quiconque de voir EXACTEMENT ce qui va se passer lorsque je lance la commande.

Cela n’a absolument rien à voir avec la qualité de ma conception d’une base de données. Cela a tout à voir avec les problèmes opérationnels introduits par les déclencheurs.

Answer 4

Au lieu d’écrire la méthode pour effectuer tout le travail, de la suppression en cascade ou de la mise à jour en cascade, vous pouvez simplement écrire un message d’avertissement. Bien plus facile que de réinventer la roue, cela est clair pour le client (et les nouveaux développeurs qui prennent le code)