Déclencheurs de base de données

Question

Dans le passé, je n'ai jamais été fan de l'utilisation de déclencheurs sur les tables de base de données.Pour moi, ils représentaient toujours une certaine « magie » qui allait se produire du côté de la base de données, très loin du contrôle de mon code d'application.Je voulais également limiter la quantité de travail que la base de données devait effectuer, car il s'agit généralement d'une ressource partagée et j'ai toujours supposé que les déclencheurs pouvaient devenir coûteux dans des scénarios de charge élevée.

Cela dit, j'ai trouvé quelques cas où les déclencheurs étaient logiques à utiliser (du moins à mon avis, ils avaient du sens).Cependant, récemment, je me suis retrouvé dans une situation où je devais parfois « contourner » le déclencheur.Je me sentais vraiment coupable de devoir chercher des moyens d'y parvenir, et je pense toujours qu'une meilleure conception de base de données atténuerait le besoin de ce contournement.Malheureusement, cette base de données est utilisée par plusieurs applications, dont certaines sont maintenues par une équipe de développement très peu coopérative et qui crierait sur les changements de schéma, j'étais donc coincé.

Quel est le consensus général sur les déclencheurs ?Vous les aimez ?Je les déteste?Vous pensez qu'ils servent à quelque chose dans certains scénarios ?Pensez-vous qu'avoir besoin de contourner un déclencheur signifie que vous « le faites mal » ?

Answer 1

Les déclencheurs sont généralement mal utilisés, introduisent des bugs et doivent donc être évités.Ne concevez jamais de déclencheur pour effectuer une vérification des contraintes d'intégrité qui traverse les lignes d'un tableau (par exemple, "le salaire moyen par service ne peut pas dépasser X).

Tom Kyte, le vice-président d'Oracle a indiqué qu'il préférerait supprimer les déclencheurs en tant que fonctionnalité d'Oracle base de données en raison de leur rôle fréquent dans les bogues.Il sait que ce n'est qu'un rêve et que les déclencheurs sont là pour rester, mais s'il le pouvait, il supprimerait les déclencheurs d'Oracle, il le ferait (avec la clause WHEN OTHERS et les transactions autonomes).

Les déclencheurs peuvent-ils être utilisés correctement ?Absolument.

Le problème est - ils ne sont pas utilisés correctement dans tant de cas que je serais prêt à abandonner tout avantage perçu juste pour se débarrasser des abus (et des bogues) causés par eux.-Tom Kyte

Answer 2

Considérez une base de données comme un très gros objet : après chaque appel, elle doit être dans un état logiquement cohérent.

Les bases de données s'exposent via des tables, et le maintien de la cohérence des tables et des lignes peut être effectué avec des déclencheurs.Une autre façon de les maintenir cohérents consiste à interdire l'accès direct aux tables et à l'autoriser uniquement via des procédures et des vues stockées.

L’inconvénient des déclencheurs est que n’importe quelle action peut les invoquer ;c'est aussi une force : personne ne va détruire l'intégrité du système par incompétence.

En contrepoint, autoriser l'accès à une base de données uniquement via des procédures et des vues stockées permet toujours l'accès dérobé aux autorisations.Les utilisateurs disposant d'autorisations suffisantes sont censés ne pas briser l'intégrité de la base de données, tous les autres utilisent des procédures stockées.

Quant à la réduction de la quantité de travail :les bases de données sont incroyablement efficaces lorsqu'elles n'ont pas à faire face au monde extérieur ;vous seriez vraiment surpris de voir à quel point même le changement de processus nuit aux performances.C'est un autre avantage des procédures stockées :plutôt qu'une douzaine d'appels à la base de données (et tous les allers-retours associés), il y en a un.

Regrouper des éléments dans un seul processus stocké est une bonne chose, mais que se passe-t-il en cas de problème ?Supposons que vous ayez 5 étapes et que la première étape échoue, qu'arrive-t-il aux autres étapes ?Vous devez y ajouter tout un tas de logique pour répondre à cette situation.Une fois que vous commencez à faire cela, vous perdez les avantages de la procédure stockée dans ce scénario.

La logique métier doit aller quelque part, et de nombreuses règles de domaine implicites sont intégrées dans la conception d'une base de données - les relations, les contraintes, etc. sont une tentative de codifier les règles métier en disant, par exemple, qu'un utilisateur ne peut avoir qu'un seul mot de passe.Étant donné que vous avez commencé à insérer des règles métier sur le serveur de base de données en établissant ces relations, etc., où tracez-vous la limite ?Quand la base de données abandonne-t-elle la responsabilité de l’intégrité des données et commence-t-elle à faire confiance aux applications appelantes et aux utilisateurs de la base de données pour faire les choses correctement ?Les procédures stockées contenant ces règles intégrées peuvent placer une grande partie du pouvoir politique entre les mains des administrateurs de base de données.Cela dépend du nombre de niveaux qui existeront dans votre architecture à n niveaux ;S'il existe une couche de présentation, d'activité et de données, où se situe la séparation entre l'activité et les données ?Quelle valeur ajoutée la couche métier apporte-t-elle ?Allez-vous exécuter la couche métier sur le serveur de base de données sous forme de procédures stockées ?

Oui, je pense que devoir contourner un déclencheur signifie que vous « le faites mal » ;dans ce cas, un déclencheur n'est pas pour vous.

Answer 3

Je travaille avec des applications Web et Winforms en C# et je DÉTESTER se déclenche avec passion.Je n'ai jamais rencontré de situation dans laquelle je pourrais justifier l'utilisation d'un déclencheur plutôt que de déplacer cette logique dans la couche métier de l'application et d'y répliquer la logique du déclencheur.

Je ne fais aucun travail de type DTS ou quoi que ce soit du genre, donc il pourrait y avoir des cas d'utilisation pour utiliser le déclencheur ici, mais si quelqu'un dans l'une de mes équipes dit qu'il pourrait vouloir utiliser un déclencheur, il aurait intérêt à bien préparer ses arguments. parce que je refuse de rester les bras croisés et de laisser des déclencheurs être ajoutés à n'importe quelle base de données sur laquelle je travaille.

Quelques raisons pour lesquelles je n'aime pas les déclencheurs :

• Ils déplacent la logique dans la base de données.Une fois que vous commencez à faire cela, vous demandez un monde de douleur parce que vous perdez votre débogage, votre sécurité au moment de la compilation, votre flux logique.Tout est en descente.
• La logique qu’ils mettent en œuvre n’est facilement visible pour personne.
• Tous les moteurs de base de données ne prennent pas en charge les déclencheurs. Votre solution crée donc des dépendances sur les moteurs de base de données.

Je suis sûr que je pourrais penser à d'autres raisons qui me viennent à l'esprit, mais celles-là seules me suffisent pour ne pas utiliser de déclencheurs.

Answer 4

"Ne concevez jamais un déclencheur pour effectuer une vérification des contraintes d'intégrité qui traverse les lignes d'un tableau" - je ne peux pas être d'accord.La question est étiquetée « SQL Server » et les clauses des contraintes CHECK dans SQL Server ne peuvent pas contenir de sous-requête ;Pire encore, l'implémentation semble avoir une hypothèse « codée en dur » selon laquelle un CHECK n'impliquera qu'une seule ligne, donc l'utilisation d'une fonction n'est pas fiable.Donc, si j'ai besoin d'une contrainte qui implique légitimement plus d'une ligne - et un bon exemple ici est la clé primaire séquencée dans une table temporelle classique « heure de validité » où je dois empêcher les périodes qui se chevauchent pour la même entité - comment puis-je Je fais ça sans déclencheur ?N'oubliez pas qu'il s'agit d'une clé primaire, quelque chose qui garantit l'intégrité des données, il est donc hors de question de l'appliquer ailleurs que dans le SGBD.Jusqu'à ce que les contraintes CHECK obtiennent des sous-requêtes, je ne vois pas d'alternative à l'utilisation de déclencheurs pour certains types de contraintes d'intégrité.

Answer 5

Les déclencheurs peuvent être très utiles.Ils peuvent aussi être très dangereux.Je pense qu'ils conviennent parfaitement aux tâches de nettoyage telles que le remplissage des données d'audit (créées par, date de modification, etc.) et dans certaines bases de données, ils peuvent être utilisés pour l'intégrité référentielle.

Mais je ne suis pas un grand fan de l’idée d’y mettre beaucoup de logique métier.Cela peut rendre le support problématique car :

• c'est une couche supplémentaire de code à rechercher
• parfois, comme l'OP l'a appris, lorsque vous devez effectuer une correction de données, le déclencheur peut faire les choses en supposant que la modification des données se fait toujours via une directive d'application et non par un développeur ou un administrateur de base de données résolvant un problème, ou même par un autre application

Quant au fait de devoir contourner un déclencheur pour faire quelque chose, cela peut signifier que vous faites quelque chose de mal, ou cela peut signifier que le déclencheur fait quelque chose de mal.

La règle générale que j'aime utiliser avec les déclencheurs est de les garder légers, rapides, simples et aussi non invasifs que possible.

Answer 6

Je me retrouve à contourner les déclencheurs lors des importations de données en masse.Je pense que c'est justifié dans de telles circonstances.

Si vous finissez par contourner les déclencheurs très souvent, vous devrez probablement réexaminer la raison pour laquelle vous les avez placés là en premier lieu.

En général, je voterais pour "ils servent à quelque chose dans certains scénarios".Je suis toujours nerveux quant aux implications en termes de performances.

Answer 7

Je ne suis pas fan, personnellement.Je les utiliserai, mais seulement lorsque je découvrirai un goulot d'étranglement dans le code qui peut être résolu en déplaçant des actions dans un déclencheur.En général, je préfère la simplicité et une façon de garder les choses simples est de conserver la logique au même endroit : l’application.J'ai également travaillé sur des métiers où l'accès est très cloisonné.Dans ces environnements, plus j'intègre de code dans les déclencheurs, plus je dois engager de personnes pour les correctifs les plus simples.

Answer 8

J'ai utilisé les déclencheurs pour la première fois il y a quelques semaines.Nous avons changé un serveur de production de SQL 2000 à SQL 2005 et nous avons constaté que les pilotes se comportaient différemment avec les champs NText (stockant un gros document XML), supprimant le dernier octet.J'ai utilisé un déclencheur comme solution temporaire pour ajouter un octet factice supplémentaire (un espace) à la fin des données, résolvant ainsi notre problème jusqu'à ce qu'une solution appropriée puisse être déployée.

En dehors de ce cas spécial et temporaire, je dirais que je les éviterais car ils cachent ce qui se passe et la fonction qu'ils fournissent devrait être gérée explicitement par le développeur plutôt que comme une magie cachée.

Answer 9

Honnêtement, la seule fois où j'utilise des déclencheurs pour simuler un index unique autorisé à avoir NULL qui ne compte pas pour l'unicité.

Answer 10

Quant à la réduction de la quantité de travail :les bases de données sont incroyablement efficaces lorsqu'elles n'ont pas à faire face au monde extérieur ;vous seriez vraiment surpris de voir à quel point même le changement de processus nuit aux performances.C'est un autre avantage des procédures stockées :plutôt qu'une douzaine d'appels à la base de données (et tous les allers-retours associés), il y en a un.

c'est un peu hors sujet, mais vous devez également être conscient que vous n'envisagez cela que d'un seul point positif potentiel.

Regrouper des éléments dans un seul processus stocké est une bonne chose, mais que se passe-t-il en cas de problème ?Supposons que vous ayez 5 étapes et que la première étape échoue, qu'arrive-t-il aux autres étapes ?Vous devez y ajouter tout un tas de logique pour répondre à cette situation.Une fois que vous commencez à faire cela, vous perdez les avantages de la procédure stockée dans ce scénario.

Answer 11

Fan total,

mais il faut vraiment l'utiliser avec parcimonie quand,

• Nécessité de maintenir la cohérence (en particulier lorsque les tables de dimensions sont utilisées dans un entrepôt et que nous devons relier les données de la table de faits à leur dimension appropriée.Parfois, la ligne appropriée dans la table de dimensions peut être très coûteuse à calculer, vous souhaitez donc que la clé soit écrite directement dans la table de faits, un bon moyen de maintenir cette « relation » est avec le déclencheur.

• Besoin de consigner les modifications (dans une table d'audit par exemple, il est utile de savoir quel @@utilisateur a effectué la modification et quand elle s'est produite)

Certains SGBDR comme SQL Server 2005 vous fournissent également des déclencheurs sur les instructions CREATE/ALTER/DROP (afin que vous puissiez savoir qui a créé quelle table, quand, a supprimé quelle colonne, quand, etc.)

Honnêtement, en utilisant des déclencheurs dans ces 3 scénarios, je ne vois pas pourquoi auriez-vous besoin de les "désactiver".

Answer 12

La règle générale est la suivante :n'utilisez pas de déclencheurs.Comme mentionné précédemment, ils ajoutent une surcharge et une complexité qui peuvent facilement être évitées en déplaçant la logique hors de la couche base de données.

De plus, dans MS SQL Server, les déclencheurs sont déclenchés une fois par commande SQL et non par ligne.Par exemple, l'instruction SQL suivante n'exécutera le déclencheur qu'une seule fois.

UPDATE tblUsers
SET Age = 11
WHERE State = 'NY'

De nombreuses personnes, dont moi-même, avaient l'impression que les déclencheurs étaient déclenchés à chaque ligne, mais ce n'est pas le cas.Si vous disposez d'une instruction SQL comme celle ci-dessus qui peut modifier les données de plusieurs lignes, vous souhaiterez peut-être inclure un curseur pour mettre à jour tous les enregistrements affectés par le déclencheur.Vous pouvez voir à quel point cela peut devenir compliqué très rapidement.