Les bases de données déclenchent-elles le mal?
Les déclencheurs de base de données sont-ils une mauvaise idée?
D'après mon expérience, ils sont pervers, car ils peuvent entraîner des effets secondaires surprenants et sont difficiles à résoudre (en particulier lorsqu'un déclencheur en déclenche un autre). Souvent, les développeurs ne pensent même pas à rechercher un déclencheur.
D'un autre côté, il semble que si vous avez une logique qui doit se produire chaque fois qu'un nouveau FOO est créé dans la base de données, l'emplacement le plus infaillible pour le mettre est un déclencheur d'insertion sur la table FOO.
La seule fois où nous utilisons des déclencheurs concerne des choses très simples, telles que la définition de ModifiedDate.
Les principaux problèmes avec les déclencheurs sont a) ils sont complètement globaux - ils s'appliquent quel que soit le contexte de l'activité de la table; et b) ils sont furtifs; il est facile d'oublier qu'ils sont là jusqu'à ce qu'ils vous blessent avec des conséquences inattendues (et très mystérieuses).
Ce qui signifie simplement qu'ils doivent être utilisés avec soin dans les circonstances appropriées; ce qui, selon mon expérience, est limité aux problèmes d'intégrité relationnelle (parfois avec une granularité plus fine que celle que vous pouvez obtenir de manière déclarative); et généralement pas à des fins commerciales ou transactionnelles. YMMV.
Non, ils sont en fait une bonne idée. S'il y a un problème avec vos déclencheurs spécifiques, alors vous ne les exécutez pas correctement, mais cela signifie généralement qu'il y a un problème avec votre implémentation, pas le concept de déclencheurs eux-mêmes :-).
Nous utilisons beaucoup de déclencheurs car cela place l'activité spécifique au SGBD sous le contrôle de la base de données à laquelle elle appartient. Les utilisateurs d'un SGBD ne devraient pas avoir à s'inquiéter de ce genre de choses. L'intégrité des données repose sur la base de données elle-même, pas les applications ou les utilisateurs qui l'utilisent. Sans contraintes, déclencheurs et autres fonctionnalités de la base de données, il appartient aux applications de faire respecter les règles et il suffit d'une application/d'un utilisateur non fiable ou bogué pour détruire les données.
Par exemple, sans déclencheurs, il n’existerait pas de choses merveilleuses telles que les colonnes générées automatiquement et vous auriez à traiter une fonction sur chaque ligne lors de la sélection. Cela risque de nuire aux performances du SGBD. Il est bien mieux de créer la colonne générée automatiquement au moment de l'insertion/de la mise à jour, car c'est la seule fois où elle change.
En outre, l'absence de déclencheurs empêcherait l'application de règles de données au niveau du SGBD, telles que les pré-déclencheurs, afin de garantir que les colonnes ont un format spécifique. Notez que cela diffère des règles d'intégrité des données, qui ne sont généralement que des recherches de clés étrangères.
Les outils ne sont jamais mauvais. Les applications de ces outils peuvent être diaboliques.
Les déclencheurs semblent bien fonctionner pour la journalisation d'audit.
Je suis d'accord. Les problèmes avec les déclencheurs concernent les personnes, pas les déclencheurs. Bien que ce soit davantage à regarder, davantage à prendre en compte et à augmenter la charge de travail des codeurs qui vérifient les choses correctement, nous ne supprimons pas les index pour nous simplifier la vie. (Les mauvais index peuvent être aussi mauvais que les mauvais déclencheurs)
L'importance des déclencheurs (dans mon esprit) est que ...
- Tout système doit toujours être dans un état valide
- Le code pour appliquer cet état valide doit être centralisé (non écrit dans chaque SP)
Du point de vue de la maintenance, un déclencheur est très utile aux codeurs compétents et aux problèmes des développeurs plus débutants/amateurs. Pourtant, ces personnes ont besoin d'apprendre et de grandir d'une manière ou d'une autre.
Je suppose que cela dépend de votre environnement de travail. Avez-vous des personnes fiables qui apprennent bien et qui peuvent être fiables pour être méthodiques? Sinon, vous avez apparemment deux choix:
- Acceptez le fait que vous devrez perdre certaines fonctionnalités pour compenser
- Acceptez le fait que vous avez besoin de personnes différentes ou d'une meilleure formation et gestion
Ils ont l'air dur, et je suppose qu'ils le sont. Mais c'est la vérité fondamentale, dans mon esprit ...
Je pense que les déclencheurs ne sont pas seulement diaboliques, mais nécessaires à la bonne conception des bases de données. Les programmeurs d'applications pensent que les bases de données ne sont affectées que par leur application. Ils ont souvent tort. Si l'intégrité des données doit être maintenue, peu importe d'où vient le changement de données, il est nécessaire de les déclencher et il est insensé de les éviter, car certains programmeurs sont trop ethnocentriques pour considérer qu'un élément autre que leur application prisé peut avoir des conséquences. Il n’est pas difficile de concevoir, de tester ou de dépanner un déclencheur si vous êtes un développeur de base de données compétent. Il n'est pas non plus difficile de déterminer qu'un déclencheur est à l'origine d'un résultat inattendu s'il vous vient (comme il me le fait) d'y regarder. Si j'obtiens une erreur en disant qu'une table que je ne fais pas référence dans mon sp a une erreur FK, je sais sans même y penser que le déclencheur est la cause du problème et que tout développeur de base de données compétent le devrait également. Mettre les règles métier uniquement dans l'application est la première cause des mauvaises données que j'ai identifiées, car les autres n'ont aucune idée de l'existence d'une règle et la violent dans leurs processus. Les règles centrées sur les données appartiennent à la base de données et les déclencheurs sont essentiels pour appliquer les règles les plus complexes.
Surtout oui.
La difficulté avec un déclencheur est qu’il fait des choses "derrière le dos"; le développeur qui gère l'application peut facilement ne pas s'en rendre compte et effectuer des modifications qui gâchent tout, sans même s'en rendre compte.
Cela crée une couche de complexité qui ne fait qu'ajouter du travail de maintenance.
Plutôt que d'utiliser un déclencheur, une procédure/routine stockée peut généralement être amenée à faire la même chose, mais de manière claire et facile à gérer - appeler une routine stockée signifie que le développeur peut consulter son code source et voir exactement ce qui se passe.
Les déclencheurs sont extrêmement puissants et utiles. Il existe de nombreux scénarios dans lesquels un déclencheur est la meilleure solution à un problème.
Ils sont également un très bon outil de "piratage". Il arrive souvent que vous ne contrôliez pas immédiatement le code et la base de données. Si vous devez attendre 2 mois pour la prochaine version majeure de votre code, mais que vous puissiez appliquer immédiatement un correctif à votre base de données, vous pouvez activer un déclencheur sur une table pour apporter des fonctionnalités supplémentaires. Ensuite, lorsque la libération du code est possible, vous pouvez remplacer ce déclencheur par votre version codée de la même fonctionnalité si vous le souhaitez.
À la fin de la journée, tout est "diabolique" si vous ne savez pas ce que ça fait. Décider que les déclencheurs sont dus au fait que certains développeurs ne les comprennent pas revient à dire que les voitures sont mauvaises, car certaines personnes ne peuvent pas conduire ...
Les déclencheurs ont leurs utilisations - la journalisation/vérification et le maintien d'une date de "dernière modification" sont deux très bonnes utilisations qui ont été mentionnées dans les réponses précédentes.
Cependant, l'un des principes de base d'une bonne conception est que les règles métier/la logique métier/celle que vous voulez appeler doivent être concentrées dans un seul endroit. Placer une partie de la logique dans la base de données (via des déclencheurs ou des processus stockés) et une partie de l'application enfreignent ce principe. La duplication de la logique dans les deux endroits est encore pire, car ils seront toujours désynchronisés les uns des autres.
Il y a aussi le problème du "principe de la moindre surprise" qui a déjà été mentionné.
À un niveau élevé, il y a deux cas d'utilisation pour les déclencheurs1
1) Faire des choses "automatiquement". Dans ce cas, les déclencheurs provoquent un effet secondaire, ils modifient les données de manière inattendue compte tenu de l'opérateur (primitif) insertion, mise à jour ou suppression exécuté et ayant déclenché le déclenchement.
Le consensus général est que les déclencheurs sont en effet néfastes. Parce qu'ils changent la sémantique bien connue d'une instruction INSERT, UPDATE ou DELETE. Changer la sémantique de ces trois opérateurs SQL primitifs piquera d’autres développeurs qui devront plus tard travailler sur vos tables de base de données qui ne se comportent plus de la manière attendue lorsqu’elles sont manipulées avec les primitives SQL.
2) Pour appliquer des règles d'intégrité des données, autres que celles auxquelles nous pouvons nous conformer de manière déclarative (à l'aide de CHECK, PRIMARY KEY, UNIQUE KEY et FOREIGN KEY). Dans ce cas d'utilisation, tous les déclencheurs font des données QUERY (SELECT) pour vérifier si la modification effectuée par INSERT/UPDATE/DELETE est autorisée ou non. Tout comme les contraintes déclaratives le font pour nous. Seulement dans ce cas, nous (les développeurs) avons programmé l'application.
L'utilisation de déclencheurs pour ce dernier cas d'utilisation n'est pas nocive.
Je blogue à ce sujet sur: http://harmfultriggers.blogspot.com
Les déclencheurs sont un bon outil s’ils sont utilisés correctement. Notamment pour l'audit des modifications, le remplissage des tableaux de synthèse, etc.
Maintenant, ils peuvent être "diaboliques" si vous vous retrouvez dans "trigger hell" avec un déclencheur qui déclenche d'autres déclencheurs. J'ai déjà travaillé sur un produit COTS dans lequel ils avaient ce qu'ils appelaient des "déclencheurs de flexion". Ces déclencheurs ont été stockés dans une table lors de la compilation des fichiers SQL dynamiques chaque fois où ils ont été exécutés. Les déclencheurs compilés effectuent une recherche et voient si cette table contient des déclencheurs flex à exécuter puis à compiler et à exécuter le déclencheur "flex". En théorie, cela semblait être une idée vraiment géniale car le produit était facile à personnaliser, mais la réalité était que la base de données avait explosé à cause de toutes les compilations qu’elle avait à faire ...
Alors oui, ils sont parfaits si vous gardez ce que vous faites en perspective. Si c'est quelque chose d'assez simple, comme l'audit, la synthèse, le séquencement automatique, etc., aucun problème. Il suffit de garder à l’esprit le taux de croissance de la table et l’impact que le déclencheur aura sur les performances.
Je sais que les développeurs qui croient que les déclencheurs devraient toujours être utilisés sont le moyen le plus direct d’atteindre les fonctionnalités qu’ils souhaitent et les développeurs qui ne le feront jamais. C'est presque comme un dogme entre les deux camps.
Cependant, personnellement, je suis tout à fait d’accord avec MarkR: vous pouvez (presque) toujours écrire un code fonctionnellement équivalent au déclencheur, qui sera plus clair et donc plus facile à gérer.
Pas mal. Ils simplifient réellement des choses comme
1.Logging/audit des modifications apportées aux enregistrements ou même aux schémas de base de données
Vous pouvez avoir un déclencheur sur ALTER TABLE qui annule les modifications dans votre environnement de production. Cela devrait empêcher toute modification accidentelle de la table.
2. Appliquer une intégrité référentielle (relations de clé primaire/étrangère, etc.) dans plusieurs bases de données
Cette réponse s'applique spécifiquement à SQL Server. (Bien que cela puisse également s'appliquer à d'autres SGBDR, je n'en ai aucune idée. J'aurais préféré le donner comme réponse ici mais cela a été fermé comme une dupe.)
Un aspect qui n’a été mentionné dans aucune des réponses jusqu’à présent est la sécurité. Parce que, par défaut, les déclencheurs s'exécutent dans le contexte de l'utilisateur qui exécute l'instruction à l'origine de l'activation du déclencheur, ce qui peut entraîner une menace pour la sécurité à moins que tous les déclencheurs ne soient examinés.
L'exemple donné dans BOL sous l'en-tête " Gestion de la sécurité des déclencheurs " est celui d'un utilisateur qui crée un déclencheur contenant le code GRANT CONTROL SERVER TO JohnDoe ; afin d’élever leurs propres autorisations.
Ils ne sont définitivement pas pervers. J'ai trouvé des déclencheurs précieux lors du refactoring des schémas de base de données, lors du changement de nom d'une colonne, du fractionnement d'une colonne en deux colonnes ou inversement (exemple: cas de nom/prénom) et lors de la transition.
Ils sont également très utiles pour l'audit.
Nah, ils ne sont pas méchants, ils sont simplement incompris :-D
Les déclencheurs ont une utilisation valable, mais bien trop souvent en tant que rétro-piratage qui aggrave finalement les choses.
Si vous développez une base de données dans le cadre d'une application, la logique doit toujours figurer dans le code ou les sprocs effectuant l'appel. Les déclencheurs mèneront simplement à un débogage douloureux plus tard.
Si vous comprenez comment le verrouillage, l'interblocage et la manière dont les bases de données accèdent aux fichiers sur disque, il peut s'avérer très utile d'utiliser des déclencheurs (par exemple, l'audit ou l'archivage de l'accès direct à une base de données).
Dire qu'ils sont pervers est une exagération mais ils peuvent causer des mailles. Lorsque le déclenchement d'un déclencheur provoque le déclenchement d'autres déclencheurs, cela devient vraiment compliqué. Disons qu'ils sont gênants: http://www.Oracle.com/technology/oramag/Oracle/08-sep/o58asktom.html
La logique métier dans Oracle avec des déclencheurs est plus difficile qu'il n'y paraît en raison de problèmes de simultanéité. Vous ne verrez pas de changements dans une autre session jusqu'à ce que les autres sessions soient validées.
S'il y a des effets secondaires, c'est un problème de conception. Dans certains systèmes de base de données, il n’ya pas d’autre possibilité de définir un champ d’auto-incrémentation, c’est-à-dire un champ d’identifiant de clé primaire.
Je pense qu'ils peuvent être diaboliques, mais seulement comme diaboliques comme n'importe quoi d'autre en développement.
Bien que je n’ai pas vraiment beaucoup d’expérience avec eux, je les ai eu sur un projet récent sur lequel j’ai travaillé, ce qui m’a amené à cette conclusion. Le problème que j'ai avec eux est qu'ils peuvent amener la logique métier à se trouver dans deux emplacements, une bibliothèque de code et une base de données.
Je le vois comme un argument similaire avec l'utilisation de sprocs. Vous aurez souvent des développeurs qui savent très bien écrire la logique métier dans la base de données SQL, tandis que les autres utilisateurs auront leur logique métier ailleurs.
Ma règle générale est donc de regarder quelle est la structure de votre projet. S'il semble viable de disposer d'une logique métier stockée dans la base de données, il pourrait être utile de disposer de déclencheurs.
En effet, très souvent, les déclencheurs sont mal utilisés. En fait, dans la plupart des cas, vous n'en avez même pas besoin. Mais cela ne les rend pas nécessairement mauvais.
Un scénario qui me vient à l’esprit et où les déclencheurs sont utiles est celui où vous avez une application héritée pour laquelle vous n’avez pas le code source et où il n’est pas possible de le changer.
L’idée des déclencheurs n’est pas mauvaise, la limitation de l’imbrication des déclencheurs est mauvaise.