Déclencheurs SQL et quand ou quand ne pas les utiliser.
Lorsque j'étais à l'origine en train d'apprendre sur SQL, on m'a toujours dit de n'utiliser des déclencheurs que si vous en avez vraiment besoin et de choisir d'utiliser des procédures stockées à la place si possible.
Maintenant, malheureusement à l'époque (il y a quelques années), je n'étais pas aussi curieux et soucieux des fondamentaux que je le suis maintenant, alors je n'ai jamais demandé pourquoi.
Quelle est l'opinion des communautés à ce sujet? Est-ce simplement la préférence personnelle de quelqu'un, ou faut-il éviter les déclencheurs (tout comme les curseurs) à moins qu'il n'y ait une bonne raison pour eux.
Le article Wikipedia sur les déclencheurs de base de données présente un bon aperçu de ce que sont les déclencheurs et quand les utiliser dans différentes bases de données.
La discussion suivante est basée sur SQL Server uniquement.
L'utilisation de déclencheurs est tout à fait valable lorsque leur utilisation est justifiée. Par exemple, ils ont une bonne valeur dans l'audit (conserver l'historique des données) sans nécessiter de code procédural explicite avec chaque commande CRUD sur chaque table.
Les déclencheurs vous donnent le contrôle juste avant la modification des données et juste après la modification des données. Cela permet:
- Audit comme mentionné précédemment
- La validation et la vérification de la sécurité de l'entreprise si vous le souhaitez. En raison de ce type de contrôle, vous pouvez effectuer des tâches telles que le formatage des colonnes avant et après les insertions dans la base de données.
On m'a toujours dit de n'utiliser des déclencheurs que si vous en avez vraiment besoin et de choisir d'utiliser des procédures stockées à la place si possible.
Les raisons peuvent être les suivantes:
- Certaines fonctions que les déclencheurs effectuaient autrefois pouvaient désormais être exécutées d'une autre manière, comme la mise à jour des totaux et le calcul automatique sur une colonne.
- Vous ne voyez pas où le déclencheur est invoqué en examinant le code seul sans savoir qu'il existe. Vous voyez leur effet lorsque vous voyez les changements de données et il est parfois déroutant de comprendre pourquoi le changement s'est produit à moins que vous ne sachiez qu'il y a un déclencheur ou plus agissant sur les tables.
- Si vous utilisez plusieurs contrôles de base de données tels que CHECK, RI, Triggers sur plusieurs tables, votre flux détaillé de transaction devient complexe à comprendre et à maintenir. Vous devrez savoir exactement ce qui se passe quand. Encore une fois, vous aurez besoin d'une bonne documentation pour cela.
Certaines différences entre les déclencheurs et les procédures stockées non déclenchées sont (entre autres):
- Une procédure stockée sans déclencheur est comme un programme qui doit être invoqué explicitement à partir du code ou d'un ordonnanceur ou d'un travail par lots, etc. pour faire son travail, alors qu'un déclencheur est un type spécial de procédure stockée qui se déclenche en tant que réponse d'un événement plutôt que d'être directement exécuté par l'utilisateur. L'événement peut être un changement de données dans une colonne de données par exemple.
- Les déclencheurs ont des types. Déclencheurs DDL et déclencheurs DML (de types: INSTEAD OF, For et AFTER)
- Les procédures stockées sans déclencheur peuvent référencer tout type d'objet, cependant, pour référencer une vue, vous devez utiliser les déclencheurs INSTEAD OF.
- Dans SQLServer, vous pouvez avoir n'importe quel nombre sur les procédures stockées non déclencheuses, mais seulement 1 déclencheur INSTEAD OF par table.
Les déclencheurs sont obligatoires pour toutes les règles complexes d'intégrité des données. Ceux-ci ne peuvent pas être appliqués ailleurs que dans la base de données, sinon vous aurez des problèmes d'intégrité des données.
Ils sont également le meilleur endroit pour l'audit, sauf si vous ne souhaitez pas capturer toutes les modifications apportées à la base de données (ce qui est le problème de l'audit à partir de l'application).
Les déclencheurs peuvent entraîner des problèmes de performances s'ils ne sont pas écrits avec soin et si les développeurs ne sont pas suffisamment informés pour bien les écrire. Cela fait partie de l'endroit où ils obtiennent leur mauvais rap.
Les déclencheurs sont souvent plus lents que les autres moyens de maintenir l'intégrité des données, donc si vous pouvez utiliser une contrainte de vérification, utilisez-la à la place d'un déclencheur.
Il est facile d'écrire de mauvais déclencheurs qui font des choses stupides comme essayer d'envoyer des e-mails. Voulez-vous vraiment ne pas pouvoir modifier les enregistrements dans la base de données si le serveur de messagerie tombe en panne?
Dans SQL Server, les déclencheurs fonctionnent sur un lot d'enregistrements. Trop souvent, les développeurs pensent qu'ils n'ont besoin de gérer qu'un seul insertions, mises à jour ou suppressions d'enregistrements. Ce n'est pas le seul type de changement de données qui se produit dans une base de données et tous les déclencheurs doivent être testés dans les conditions d'un changement d'enregistrement et de nombreux changements d'enregistrement. Oublier d'effectuer le deuxième test peut entraîner des déclencheurs extrêmement peu performants ou une perte d'intégrité des données.
tilisation de déclencheurs de base de données
- Pour piloter automatiquement les valeurs des colonnes.
- Pour appliquer des contraintes d'intégrité complexes.
- Pour appliquer des règles commerciales complexes.
- Pour personnaliser des autorisations de sécurité complexes.
- Pour gérer les tables répliquées.
- Pour auditer la modification des données.
Un autre cas d'utilisation que j'ai personnellement rencontré concerne les bases de données accessibles par plusieurs programmes. Si vous souhaitez implémenter des fonctionnalités mais ne pas repenser tous les systèmes, un déclencheur constitue une solution judicieuse.
Par exemple, j'ai récemment travaillé sur une base de données qui n'existait auparavant que comme un système de bureau. Lorsqu'une webapp a été écrite pour s'interfacer avec elle, nous voulions implémenter un système de notification (similaire à stackexchange, par exemple), qui serait déclenché par plusieurs événements, tels que le traitement d'une transaction, etc. Nous avons pu implémenter un déclencheur afin que les mises à jour dans le backend du bureau déclenchent un déclencheur pour créer la notification pour le frontend et indiquer à l'utilisateur que leur transaction a été traitée par le bureau.
Les déclencheurs peuvent être utilisés pour appliquer des contraintes sur la base de données qui ne peuvent pas être appliquées lors de la création du schéma de base de données et des instructions DML.
Supposons que vous ayez besoin de transférer des données vers un système tiers en temps quasi réel. Votre table contient 950 gigaoctets de données, elle est donc trop grande pour simplement pousser la table entière vers l'application tierce.
Au lieu de cela, vous accumulez les modifications dans une file d'attente. Certains programmes externes pousseront ensuite périodiquement de petits lots de données en file d'attente.
Le système compte plus de 2000 procédures stockées. Vous savez également que des tonnes de sql existent dans le code source. Pour garantir que la file d'attente est correctement remplie, vous devrez parcourir tous les procs et codes stockés et espérer ne rien manquer.
Au lieu de cela, vous pouvez mettre un déclencheur sur la table pour maintenir la file d'attente à jour. Garanti pour ne rien manquer. Un emplacement central. Pénalité de performance? Pas vraiment parce que le coup de remplissage de la file d'attente ne peut pas être évité que ce soit par déclencheur ou externe.
Dans ce scénario, je dirais que ne pas utiliser de déclencheur est un mauvais choix de conception. Si plus tard, vous souhaitez utiliser une nouvelle méthode de transmission des données (par exemple, la file d'attente ne fonctionne pas) et que les modifications de l'interface sont protégées si vous utilisez le déclencheur. Les déclencheurs sont souvent le meilleur choix. N'écoutez pas les fanboys dogmatiques anti-trigger.