Déclencheurs SQL et quand ou quand ne pas les utiliser.

Lorsque je découvrais le langage SQL à l’origine, on me disait toujours que vous n’utilisiez que des déclencheurs si vous en aviez vraiment besoin et que vous utilisiez des procédures stockées, si possible.

Malheureusement, à l'époque (il y a quelques années), je n'étais pas aussi curieux et soucieux des fondamentaux que je ne le suis maintenant, alors je n'ai jamais demandé pourquoi.

Quelle est l'opinion des communautés à cet égard? Est-ce juste la préférence personnelle de quelqu'un, ou faut-il éviter les déclencheurs (comme les curseurs) à moins qu'il y ait une bonne raison pour cela.

L' article de Wikipedia sur les déclencheurs de base de données présente un bon aperçu de ce que sont les déclencheurs et du moment de 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 en matière d'audit (conservation de l'historique des données) sans nécessiter de code de procédure explicite pour chaque commande CRUD de chaque table.

Les déclencheurs vous donnent le contrôle juste avant la modification des données et juste après. Cela permet de:

• Audit comme mentionné précédemment
• Validation et vérification de la sécurité de l'entreprise, le cas échéant. 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 que des déclencheurs si vous en avez vraiment besoin et de choisir d'utiliser des procédures stockées à la place si possible.

Peut-être que certaines des raisons en sont:

1. Certaines fonctions que les déclencheurs utilisaient auparavant pouvaient désormais être exécutées de différentes manières, telles que la mise à jour des totaux et le calcul automatique sur une colonne.
2. Vous ne voyez pas où le déclencheur est invoqué en examinant le code seul sans savoir qu'il existe. Vous voyez leurs effets lorsque vous voyez les modifications de données et il est parfois difficile de comprendre pourquoi ces modifications ont eu lieu, à moins que vous ne sachiez qu'il existe un déclencheur ou davantage qui agit sur la (les) table (s).
3. Si vous utilisez plusieurs contrôles de base de données tels que CHECK, RI et des déclencheurs sur plusieurs tables, le flux détaillé de votre transaction devient complexe à comprendre et à gérer. Vous aurez besoin de savoir exactement ce qui se passe quand. Encore une fois, vous aurez besoin d’une bonne documentation pour cela.

Certaines différences entre les procédures stockées déclencheurs et non déclencheurs sont (entre autres):

• Une procédure stockée sans déclencheur ressemble à un programme qui doit être appelé explicitement à partir d'un code, d'un planificateur, d'un travail batch, etc. pour effectuer son travail, alors qu'un déclencheur est un type spécial de procédure stockée réponse d’un événement plutôt que d’être exécutée directement 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 OF, For et AFTER)
• Les procédures stockées non déclenchées peuvent référencer n'importe quel type d'objet. Toutefois, 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 sans déclencheur, mais un seul déclencheur INSTEAD OF par table.

Les déclencheurs sont indispensables à toute règle complexe d'intégrité des données. Celles-ci ne peuvent être appliquées que dans la base de données, sinon vous aurez des problèmes d'intégrité des données.

Ils constituent également le meilleur endroit pour l’audit, à moins que vous ne vouliez pas capturer toutes les modifications apportées à la base de données (ce qui pose le problème de l’audit à partir de l’application).

Les déclencheurs peuvent causer 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 les écrire correctement. Cela fait partie de l'endroit où ils ont leur mauvaise réputation.

Les déclencheurs sont souvent plus lents que les autres moyens de maintenir l'intégrité des données. Par conséquent, si vous pouvez utiliser une contrainte de vérification, utilisez-la au lieu d'un déclencheur.

Il est facile d'écrire de mauvais déclencheurs qui font des choses stupides, comme essayer d'envoyer des courriels. Voulez-vous vraiment ne pas pouvoir modifier les enregistrements de la base de données si le serveur de messagerie tombe en panne?

Dans SQL Server, les déclencheurs opèrent sur un lot d'enregistrements. Trop souvent, les développeurs pensent qu’ils n’ont besoin que de gérer un seul insert d’enregistrement, une mise à jour ou une suppression. Ce n'est pas le seul type de modification de données qui se produit dans une base de données et tous les déclencheurs doivent être testés dans les conditions suivantes: changement d'un enregistrement et de nombreux changements d'enregistrement. Oublier de faire le deuxième test peut entraîner des déclenchements extrêmement médiocres ou une perte de l'intégrité des données.

Utilisation de déclencheurs de base de données

1. Pour gérer les valeurs de colonne automatiquement.
2. Appliquer des contraintes d’intégrité complexes.
3. Appliquer des règles métier complexes.
4. Pour personnaliser les autorisations de sécurité complexes.
5. Maintenir les tables répliquées.
6. Auditer la modification des données.

Un autre cas d’utilisation que j’ai personnellement rencontré concerne les bases de données auxquelles ont accès plusieurs programmes. Si vous souhaitez implémenter des fonctionnalités sans modifier leur conception, un déclencheur est une solution judicieuse.

Par exemple, j'ai récemment travaillé sur une base de données qui existait auparavant uniquement en tant que système de bureau. Lorsqu'une application Web était conçue pour s'y connecter, nous voulions mettre en place 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 front-end et informer 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 d'un schéma de base de données et de toute instruction DML.

Disons que vous devez transmettre des données à un système tiers presque en temps réel. Votre table contient 950 gigaoctets de données. Il est donc trop gros pour que vous puissiez simplement transférer l'intégralité de la table dans l'application tierce.

Au lieu de cela, vous accumulez les modifications dans une file d'attente. Certains programmes externes extrairont ensuite périodiquement de petits lots de données en file d'attente.

Le système a 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 devez rechercher dans 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 de ne rien manquer. Un emplacement central. Pénalité de performance? Pas vraiment parce que le 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 vous souhaitez utiliser ultérieurement une nouvelle méthode de transfert de données (par exemple, la file d'attente ne fonctionne pas) et que l'interface change, vous êtes protégé si vous utilisez le déclencheur. Les déclencheurs sont souvent le meilleur choix. N'écoutez pas les fans dogmatiques anti-déclencheurs.

Un déclencheur qui envoie un courrier électronique n’est pas nécessairement une idée «stupide». Ce qui est stupide est de ne pas anticiper les pannes de courrier électronique dans la conception et de les gérer sans perte de données. La partie "stupide" de ceci est vraiment mauvaise pour la gestion des erreurs inexistantes par des développeurs paresseux qui se sentent immunisés contre les erreurs.

Je voudrais également faire observer qu’un déclencheur peut être gardé simple en appelant une procédure / fonction stockée qui peut être arbitrairement compliquée et peut être réutilisée par plusieurs déclencheurs ou d’autres procédures stockées. C'est pourquoi il existe des packages et des bibliothèques.

La bigoterie est vraiment invalidante.