Les bases de données sont-elles mauvaises? [fermé]


191

Les déclencheurs de base de données sont-ils une mauvaise idée?

D'après mon expérience, ils sont mauvais, car ils peuvent entraîner des effets secondaires surprenants et sont difficiles à déboguer (surtout lorsqu'un déclencheur en déclenche un autre). Souvent, les développeurs ne pensent même pas à chercher s'il y a 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 FOOest créé dans la base de données, alors l'endroit le plus infaillible pour le placer est un déclencheur d'insertion sur la table FOO.

La seule fois où nous utilisons des déclencheurs, c'est pour des choses vraiment simples comme la configuration du ModifiedDate.


32
C'est une question tout à fait légitime mais je n'aime pas vraiment le titre sensationnaliste. Je pense quelque chose comme "Quels sont les problèmes les plus importants à prendre en compte lors de la mise en œuvre des déclencheurs de base de données?" serait beaucoup mieux.
Tamas Czinege

2
La question est fermée pour l'ajout de réponses, mais voir également Les déclencheurs de base de données sont-ils sûrs pour les contraintes d'intégrité entre tables? . (Spoiler: non, ils ne le sont pas)
Mifeet

18
Ce site me fait tellement chier. C'est une GRANDE question mais comme beaucoup d'autres, elle est fermée parce que les gens manquent d'imagination pour accepter des questions qui ne rentrent pas dans le format binaire primitif des questions-réponses qu'ils se sentent obligés de suivre pour une raison extraterrestre.
Quibblesome

1
La logique métier dans un déclencheur est problématique (mal, si vous voulez). La logique de base de données dans un déclencheur n'est pas problématique (intégrité, journalisation).
Greg Gum

1
J'aime me fier à l'IDE pour la navigation dans le code et pour comprendre ce qui se passe. Je ne peux pas faire cela si la moitié de la logique est dans la base de données et l'autre moitié dans le langage de programmation de choix. Au lieu de déclencheurs, je trouve plus facile de créer un contrôleur que chaque demande doit passer. Tous les «déclencheurs» peuvent être appliqués à la place.
Muhammad Umer

Réponses:


153

Les principaux problèmes liés aux déclencheurs sont

  • Ils sont complètement globaux - ils s'appliquent quel que soit le contexte de l'activité de la table;
  • Ils sont furtifs; il est facile d'oublier qu'ils sont là jusqu'à ce qu'ils vous blessent avec des conséquences involontaires (et très mystérieuses).

Cela signifie simplement qu'ils doivent être soigneusement utilisés pour les circonstances appropriées; qui, d'après mon expérience, se limite 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.


21
Ce sont 2 avantages, dans certains cas.
Johnno Nolan le

18
"Stealthy" est un mot génial, oui - bien dit. C'est exactement pourquoi j'ai tendance à m'en éloigner: trop souvent, ils sont oubliés ou ignorés. D'après mon expérience personnelle, revisiter les déclencheurs est souvent accompagné d'une claque sur mon propre front.
Christian Nunciato

5
Global est pourquoi ils sont bons et nécessaires pour l'intégrité des données et des choses comme l'audit. Ce n'est pas un moins, c'est un plus.
HLGEM

4
Alors @ RobertŠevčík-Robajz, vous dites que tous les développeurs que vous connaissez sont incomptables?
HLGEM

3
@HGLEM, d'accord qu'il devrait y avoir un spécialiste pour déterminer les déclencheurs. Scénario de la vraie vie - il n'y en a pas. Scénario de la vie réelle - jours passés à essayer d'identifier un bogue lié à un déclencheur oublié. Scénario de la vie réelle - la logique de déclenchement est désespérément poussée vers la logique d'application où elle peut être facilement refactorisée et testée par unité. C'est la vraie vie avec laquelle je fais affaire qui me fait dire "éloignez-vous des déclencheurs" ... ce n'est pas la faute des déclencheurs car ce n'est pas la faute des pierres si les fenêtres se brisent.
Rbjz

82

Non, c'est en fait une bonne idée. S'il y a un problème avec vos déclencheurs spécifiques, alors vous ne les faites pas correctement, mais cela signifie généralement qu'il y a un problème avec votre implémentation, pas le concept des déclencheurs eux-mêmes :-).

Nous utilisons beaucoup les déclencheurs car ils placent 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 à se soucier de ce genre de choses. L'intégrité des données réside dans la base de données elle-même, et non dans les applications ou les utilisateurs qui l'utilisent. Sans contraintes, déclencheurs et autres fonctionnalités dans la base de données, il appartient aux applications d'appliquer les règles et il suffit d'une application / d'un utilisateur non autorisé ou bogué pour détruire les données.

Par exemple, sans déclencheurs, des choses aussi merveilleuses que les colonnes générées automatiquement n'existeraient pas et vous auriez à traiter une fonction sur chaque ligne lors de leur sélection. Cela risque de tuer les performances du SGBD, il est préférable 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 SGBD, telles que les pré-déclencheurs, pour garantir que les colonnes ont un format spécifique. Notez que cela est différent des règles d'intégrité des données qui ne sont généralement que des recherches de clés étrangères.


9
"traiter une fonction sur chaque ligne lors de leur sélection". Il est préférable d'utiliser un index basé sur une fonction à cet effet plutôt qu'un déclencheur.
tuinstoel le

10
Pas nécessairement, le déclencheur ne s'exécutera probablement que lorsque la ligne sera insérée ou mise à jour. L'index basé sur la fonction s'exécutera pour chaque sélection. Selon le modèle d'utilisation, l'un est probablement meilleur que l'autre. Mais ni l'un ni l'autre n'est TOUJOURS meilleur que l'autre.
jmucchiello

@tuinstoel: Je suis d'accord avec votre déclaration un peu du temps. Oracle, par exemple, ne créera des index basés sur des fonctions que s'il peut prouver que la fonction est déterministe. Parfois, cela ne peut tout simplement pas être prouvé (par exemple, si la fonction implique une recherche dans une table, même si vous savez que les données de la table ne changent jamais).
Adam Paynter

51

Les outils ne sont jamais mauvais. Les applications de ces outils peuvent être mauvaises.


12
Je n'ai jamais été aussi en conflit après avoir lu un commentaire. D'une part, je suis favorable au deuxième amendement et je crois que les armes à feu ne sont pas intrinsèquement mauvaises: c'est la personne qui les utilise. D'un autre côté, je crois que les déclencheurs SONT mauvais ... Je pense que je suis en train de faire un effondrement existentiel ...
vbullinger

41
Les armes à feu @vbullinger ne sont pas mauvaises, mais leurs déclencheurs le sont;)
Darragh Enright

2
: D Les généralisations sont dangereuses (récursivement). Êtes-vous venu par les «outils» de torture utilisés par les inquisiteurs pour «déclencher» une confession? +1 pour la perspective de toute façon.
Rbjz

22

Je suis d'accord. Les problèmes avec les déclencheurs, ce sont les gens, pas les déclencheurs. Bien que ce soit plus à regarder, plus à considérer et augmente le fardeau des codeurs qui vérifient correctement les choses, 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é (pas écrit dans chaque SP)

Du point de vue de la maintenance, un déclencheur est très utile pour les codeurs concurrents et les problèmes pour les plus juniors / 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 sont méthodiques? Sinon, vous avez apparemment deux choix:
- Acceptez de perdre des fonctionnalités pour compenser
- Acceptez que vous ayez besoin de personnes différentes ou d'une meilleure formation et d'une meilleure gestion

Ils semblent durs, et je suppose qu'ils le sont. Mais c'est la vérité fondamentale, dans mon esprit ...


4
>>> Les problèmes avec les déclencheurs, ce sont les gens. Ouais, si seulement les gens pouvaient coder en assemblage, travailler avec une interface graphique merdique, deviner correctement s'il fallait pousser ou tirer une porte mal conçue ... Toute "fonctionnalité" que les gens se trompent à plusieurs reprises est "diabolique".
Fakrudeen

1
@Fakrudeen, tout développeur qui obtient des déclencheurs erronés est incompétent pour accéder à une base de données.
HLGEM

21

Je pense que les déclencheurs ne sont pas seulement mauvais, mais nécessaires à une bonne conception de base 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 préservée, quelle que soit l'origine du changement de données, les déclencheurs sont une exigence et il est insensé de les éviter car certains programmeurs sont trop ethnocentriques pour considérer que quelque chose d'autre que leur application prisée peut affecter les choses. 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 provoque un résultat inattendu s'il vous vient à l'esprit (comme à moi) d'y regarder. Si j'obtiens une erreur indiquant qu'une table que je ne référence pas dans mon sp a une erreur FK, Je sais sans même y penser que le déclencheur est à l'origine du problème, tout comme tout développeur de base de données compétent. Mettre des règles métier uniquement dans l'application est la principale cause que j'ai trouvée de mauvaises données car d'autres n'ont aucune idée que la règle existe même 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 plus complexes.


1
Les règles centrées sur les données appartiennent à la base de données
absin

had mesome programmers are too ethnocentric to consider that something other than their prized application may be affecting things
Kid101

13

Surtout, oui.

La difficulté avec un déclencheur est qu'il fait des trucs "derrière votre dos"; le développeur qui maintient l'application pourrait facilement ne pas se rendre compte qu'elle est là et faire des changements qui gâchent les choses sans même s'en apercevoir.

Cela crée une couche de complexité qui ne fait qu'ajouter des travaux 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 maintenable - l'appel d'une routine stockée signifie que le développeur peut consulter son code source et voir exactement ce qui se passe.


12
C'est l'avantage d'un déclencheur pas le désavantage! Il n'est pas garanti que les processus stockés soient appelés pour chaque modification des données. Il existe de nombreuses façons de modifier les données en plus de l'interface graphique.
HLGEM

2
HLGEM, cela dépend de votre contrôle d'accès. Vous pouvez refuser toute modification aux tables directement, sauf via une procédure stockée.
Rbjz

1
Je pense que le fait est que si, par exemple, des enregistrements dans deux tables doivent TOUJOURS être créés et détruits ensemble, peu importe la façon dont vous accédez à la base de données, et peu importe qui vous êtes ou quelles autorisations vous avez, les déclencheurs sont la seule solution légitime. . Le simple fait qu'il soit même possible d'attribuer des autorisations trop nombreuses ou incorrectes et de s'attendre à ce que les gens sachent quelles procédures stockées doivent être utilisées, signifie que la base de données risque de perdre son intégrité. C'est exactement la même chose que les relations de clé étrangère. C'est tout simplement MEILLEUR et PLUS FIABLEMENT appliqué par le moteur de base de données.
Triynko du

2
Si les enregistrements doivent toujours être créés / détruits ensemble, créez une contrainte de vérification qui garantit qu'ils le sont. De cette façon, quelqu'un qui enfreint les règles obtient une erreur, plutôt qu'un comportement caché qui par magie corrige les choses à leur insu ou sans leur consentement.
MarkR

9

Les déclencheurs sont extrêmement puissants et utiles, il existe un certain nombre de scénarios où un déclencheur est la meilleure solution à un problème.

Ils sont également un très bon outil de "hack". Il existe souvent des situations dans lesquelles vous ne contrôlez 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 pouvez appliquer un correctif à votre base de données immédiatement, vous pouvez mettre un déclencheur sur une table pour exécuter des fonctionnalités supplémentaires. Ensuite, lorsque la publication 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 «mal» si vous ne savez pas ce que cela fait. Décider que les déclencheurs sont dus au fait qu'il y a des développeurs qui ne les comprennent pas équivaut à affirmer que les voitures sont mauvaises parce que certaines personnes ne peuvent pas conduire ...


8

Les déclencheurs ont leurs utilisations - la journalisation / l'audit 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 fondamentaux d'une bonne conception est que les règles métier / la logique métier / tout ce que vous voulez appeler doivent être concentrés en un seul endroit. Mettre une partie de la logique dans la base de données (via des déclencheurs ou des procs stockés) et une partie dans l'application viole ce principe. La duplication de la logique dans les deux endroits est encore pire, car ils seront invariablement désynchronisés l'un avec l'autre.

Il y a aussi la question du «principe de la moindre surprise» qui a déjà été mentionnée.


3
C'est exact, cela devrait être en un seul endroit, la base de données. La logique qui affecte l'intégrité des données doit TOUJOURS se trouver dans la base de données et jamais dans une application où elle pourrait ou non être appelée lorsqu'elle affecte les données de la base de données.
HLGEM

1
@HLGEM: Cela dépend si la base de données peut éventuellement avoir accès à des informations lui permettant de dire si les données sont valides. Ce n'est pas toujours le cas. lorsque le validateur est dans une autre organisation (par exemple, pour les détails de carte de crédit ou de compte bancaire), alors la DB ne peut pas savoir si c'est juste - en supposant que ce n'est pas la DB de la banque! - et il devra s'appuyer sur la demande d'exécution. Ce que vous ne voulez pas, c'est que la base de données établisse des connexions aléatoires à des services tiers, car cela est mauvais en ce qui concerne le déploiement du serveur.
Donal Fellows

@HLGEM: Bien que je ne sois pas prêt à exclure complètement la possibilité de mettre toute la logique d'application dans la base de données, je trouve qu'il a tendance à mieux fonctionner de la placer ailleurs, généralement une couche OO réutilisable qui peut être utilisée pour toutes les applications accédant la base de données. Tant que votre application accède uniquement à la base de données via la couche objet, les mêmes garanties de la logique toujours appelée s'appliquent toujours.
Dave Sherohman

2
Je n'ai jamais travaillé sur une application métier qui insère uniquement des données dans la base de données via la couche Object et je ne veux pas travailler sur une seule. Il est stupide de placer des millions d'importations de disques ou de mises à jour de tous les prix à travers un processus conçu pour ne traiter qu'un seul enregistrement à la fois. La couche objet est exactement le mauvais endroit pour appliquer l'intégrité des données, c'est pourquoi tant de bases de données ont des problèmes d'intégrité.
HLGEM

@HLGEM C'est précisément pour cette raison que je travaille sur une extension de notre ORM pour fonctionner comme un déclencheur en utilisant un ensemble de modifications de tout dans une transaction. Cela semble un peu ridicule mais nous empêchera d'avoir toute notre logique métier dans l'application, sauf les rares fois où ce n'est pas le cas (seules quelques tables ont besoin d'une mise à jour en masse). Cela permettra également à tous les développeurs de les écrire et de les utiliser dans le langage avec lequel ils sont le plus à l'aise et où il y a accès à toutes les abstractions d'objets que nous avons construites.
Adamantish du

7

À un niveau élevé, il existe deux cas d'utilisation des déclencheurs1

1) Pour que les choses se produisent «automatiquement». Dans ce cas, les déclencheurs provoquent un effet secondaire, ils modifient les données d'une manière qui n'était pas attendue étant donné l'insertion, la mise à jour ou la suppression de l'opérateur (primitif) qui a été exécuté et a provoqué le déclenchement du déclencheur.

Le consensus général ici est que les déclencheurs sont effectivement nuisibles. Parce qu'ils modifient la sémantique bien connue d'une instruction INSERT, UPDATE ou DELETE. Changer la sémantique de ces trois opérateurs SQL primitifs mordra d'autres développeurs qui plus tard dans le futur auront besoin de travailler sur vos tables de base de données qui ne se comportent plus comme prévu lorsqu'elles sont utilisées avec les primitives SQL.

2) Pour appliquer des règles d'intégrité des données, autres que celles que nous pouvons traiter de manière déclarative (en utilisant CHECK, PRIMARY KEY, UNIQUE KEY et FOREIGN KEY). Dans ce cas d'utilisation, tout ce que font les déclencheurs est QUERY (SELECT) des données 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. Ce n'est que dans ce cas que nous (les développeurs) avons programmé l'application.

L'utilisation de déclencheurs pour ce dernier cas d'utilisation n'est pas nuisible.

Je blogue là-dessus à: http://harmfultriggers.blogspot.com


Lors de l'utilisation de déclencheurs pour l'intégrité référentielle, il est plus difficile qu'il n'y paraît de gérer les problèmes de concurrence.
WW.

2
D'accord. Mais est-ce plus facile d'utiliser d'autres moyens?
Toon Koppelaars

Je dirais que le numéro un n'est nuisible que si vous avez des développeurs incompétents.
HLGEM

Il y a BEAUCOUP de développeurs incompétents cependant lol.
hashtable

Je ne suis pas d'accord pour dire que les déclencheurs sont nuisibles. Si vous savez exactement ce que fait le déclencheur et que vous le programmez correctement, il devrait toujours fonctionner comme prévu. Le seul problème ici est sa mise en œuvre ou son utilisation incorrecte.
Delali

6

Les déclencheurs sont un bon outil lorsqu'ils sont utilisés correctement. En particulier pour des choses comme l'audit des modifications, le remplissage de tableaux de synthèse, etc.

Maintenant, ils peuvent être «mauvais» si vous vous retrouvez dans «l'enfer de déclenchement» avec un déclencheur qui déclenche d'autres déclencheurs. J'ai travaillé une fois sur un produit COTS où ils avaient ce qu'ils appelaient des "déclencheurs flexibles". Ces déclencheurs ont été stockés dans une table car les piqûres SQL dynamiques sont compilées chaque exécution. Les déclencheurs compilés feraient une recherche et voir si cette table avait des déclencheurs flex à exécuter, puis compiler et exécuter le déclencheur «flex». En théorie, cela ressemblait à une idée vraiment cool car le produit était facilement personnalisé, mais la réalité était que la base de données avait explosé à cause de toutes les compilations qu'elle devait faire ...

Alors oui, ils sont super si vous gardez ce que vous faites en perspective. S'il s'agit de quelque chose d'assez simple comme l'audit, la synthèse, le séquençage automatique, etc., pas de problème. Gardez simplement à l'esprit le taux de croissance de la table et l'impact du déclencheur sur les performances.


5

Je sais que les développeurs qui pensent que les déclencheurs devraient toujours être utilisés là où c'est le moyen le plus direct d'obtenir les fonctionnalités qu'ils souhaitent, et les développeurs qui ne le feront jamais. C'est presque un dogme entre les deux camps.

Cependant, je suis personnellement entièrement d'accord avec MarkR - vous pouvez (presque) toujours écrire du code fonctionnellement équivalent au déclencheur qui sera plus clair et donc plus facile à maintenir.


Sauf que tous ne fonctionnent pas pour atteindre une base de données qui traverse le code de l'application.
HLGEM

5

Pas mal. Ils simplifient en fait des choses comme

Enregistrement / audit des modifications des enregistrements ou même des 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.


Application de l'intrgrité référentielle (relations de clé primaire / étrangère, etc.) sur plusieurs bases de données


Vous pouvez annuler les instructions DDL?
Andrew Swan

Généralement pas. La seule façon d'arrêter cela est de supprimer cette autorisation des connexions des utilisateurs.
jmucchiello

Dans certains moteurs de base de données, vous pouvez (par exemple, PostgreSQL).
Nicolás

@Andrew - Dans SQL Server, vous pouvez. SQL Server 2005+ possède également des déclencheurs DDL qui se déclenchent sur des événements tels que ALTER TABLE.
Martin Smith

4

Non, ils ne sont pas méchants - ils sont juste mal compris :-D

Les déclencheurs ont une utilisation valable, mais beaucoup trop souvent comme un rétro-hack qui finit par aggraver les choses.

Si vous développez une base de données dans le cadre d'une application, la logique doit toujours être dans le code ou les sprocs effectuant l'appel. Les déclencheurs mèneront simplement à des problèmes de débogage 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, l'utilisation des déclencheurs de la bonne manière (par exemple l'audit ou l'archivage de l'accès direct aux bases de données) peut être très utile.


4

Dire qu'ils sont mauvais est une exagération mais ils peuvent causer du maillage. 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

Faire de 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é multiple. Vous ne voyez pas les modifications dans une autre session tant que les autres sessions ne sont pas validées.


4

Ils ne sont certainement pas mauvais. J'ai trouvé des déclencheurs précieux lors de la refactorisation des schémas de bases de données, lors du changement de nom d'une colonne, ou lors du fractionnement d'une colonne en deux colonnes ou vice-versa (exemple: cas nom / prénom) et lors de la transition.

Ils sont également très utiles pour l'audit.


4

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é donner une réponse ici mais cela a été fermé comme une dupe.)

Un aspect qui n'a été mentionné dans aucune des réponses à ce jour 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 qui provoque le déclenchement du déclencheur, cela 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 ses propres autorisations.


3

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'y a pas d'autre possibilité de définir un champ d'auto-incrémentation, c'est-à-dire pour un champ d'ID de clé primaire.


3

Je pense qu'ils peuvent être mauvais, mais seulement aussi mauvais que n'importe quoi d'autre dans le 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é et qui m'a conduit à cette conclusion. Le problème que j'ai avec eux est qu'ils peuvent amener la logique métier à se retrouver à deux endroits, une bibliothèque de codes 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 sont vraiment bons en SQL qui écrivent la logique métier dans la base de données, tandis que les personnes qui ne le sont pas auront leur logique métier ailleurs.

Ma règle d'or est donc de regarder quelle est la structure de votre projet. S'il semble viable de stocker la logique métier dans la base de données, il peut être utile d'avoir des déclencheurs.


1

En effet, les déclencheurs sont souvent 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 où les déclencheurs sont utiles est lorsque vous avez une application héritée pour laquelle vous n'avez pas le code source et qu'il n'y a aucun moyen de le changer.


1

L'idée de déclencheurs n'est pas mauvaise, limiter l'imbrication des déclencheurs est mauvaise.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.