Intégrité de la base de données: déclencheur vs clés / contraintes

Question

Mon ami et moi nous sommes disputés à propos de la conception d’une base de données.
Il fait valoir qu'il est préférable d'utiliser des déclencheurs pour assurer l'intégrité d'une base de données complexe.

Je pense qu’à cet effet, il est préférable d’utiliser des clés (primaires, uniques) et des contraintes.
Je pense que l'utilisation de déclencheurs est dangereuse, car ils fonctionnent & "En coulisse &"; et ce n'est pas facile de dire ce qui se passera après l'exécution d'une commande. De plus, si trigger a un bogue, cela peut compromettre l'intégrité de la base de données.

Qu'en pensez-vous?

Answer 1

& "; Voici une discussion AskTom sur le sujet. Il n'y a pas de règle absolue sur la question (sinon, il n'y aurait pas de débat!) ... & Quot;

Oui, il y en a. Le déclaratif est toujours préférable à la mise en œuvre procédurale. Le déclaratif est moins sujet aux erreurs. Le déclaratif est plus facile à maintenir. Le déclaratif est plus auto-documenté que mis en œuvre procéduralement. Le déclaratif est la meilleure occasion pour le SGBD d’optimiser, et le SGBD EST un meilleur optimiseur que le programmeur, la plupart du temps.

Le seul avantage des procédures implémentées est que cela signifie des emplois pour ceux qui en seraient privés si de vraies contraintes déclaratives étaient disponibles, et pas seulement pour les pauvres PK + FK que nous obtenons de SQL.

Answer 2

En fait, vous ne dites pas pourquoi votre ami pense ce qu'il pense, mais, dans tous les cas, les contraintes / clés sont le moyen standard, défini et approprié pour assurer l'intégrité des données, pour deux raisons:

• Tout le monde les connaît et vous éviterez de violer le principe de la moindre surprise en les utilisant.

• Ils sont déjà implémentés, testés et fonctionnent.

Le roulement de votre propre code d'intégrité des données ne présente aucun avantage réel. Les déclencheurs sont destinés à d'autres cas d'utilisation, tels que (par exemple) la consignation de toutes les insertions.

Answer 3

Vous n'avez pas spécifié quelle base de données, mais je supposerai un SGBD relationnel tel que Oracle ou SQL Server, conforme à la norme ANSI.

Je suppose que cela dépend de ce que vous entendez par intégrité. Si vous essayez uniquement de conserver tous les enregistrements enfants et parents et d'empêcher les orphelins, alors le RI intégré utilisant des contraintes de clé primaire et étrangère est la solution.

Si votre RI est plus compliqué, par exemple si le champ 1 de l'enregistrement parent est > 100, le champ 2 de l’enregistrement enfant doit être & Lt; 200. Des déclencheurs doivent être utilisés.

Je n’utiliserais pas de déclencheurs pour appliquer un simple RI, cette roue a déjà été inventée.

Answer 4

Je ne pense pas que ce soit bien défini, mais j’ai tendance à utiliser les contraintes DRI pour tout ce qui peut être fait dans une contrainte DRI, et à sauvegarder les déclencheurs pour ce qui ne peut pas être fait. dans une contrainte DRI (comme pour éviter les chevauchements de valeurs)