Sage d'utiliser le déclencheur pour mettre à jour une autre table?

8

J'ai une Objecttable qui est remplie à partir d'un service intégré ( que je peux changer si nécessaire ) d'une autre base de données. À certains moments, nous devons ajouter manuellement des publications dans une autre table, ObjectObjectGroup (ObjectId, ObjectGroupId)ce qui est nécessaire si elles Object.ObjectTypeont une certaine valeur entière. Étant donné que le service d'intégration ne gère pas ce type de mise à jour, je pense à ajouter un déclencheur à la table Object qui, en pseudo-code, serait le suivant:

if Object.ObjectType = 10
    begin
        if Object.ObjectNumber like '<string pattern>'
        begin
            insert into ObjectObjectGroup values...
        end
    end

Cette configuration est-elle judicieuse ou existe-t-il une meilleure solution en termes de performances?

sql-server trigger Benny Skogberg
la source

Réponses:

9

Surtout Copiez / collez ma réponse à cette question sur stackoverflow

Les déclencheurs peuvent être très séduisants, lorsque vous commencez à les utiliser, ils semblent être une solution miracle à toutes sortes de problèmes. Mais, ils font que des choses "magiques" se produisent, si vous ne connaissez pas la base de données à l'envers, cela peut sembler des choses vraiment étranges (comme des insertions dans d'autres tables, des changements de données d'entrée, etc.). Avant d'implémenter les choses comme déclencheur, j'envisagerais sérieusement d'imposer l'utilisation d'une API autour du schéma (de préférence dans la base de données, mais à l'extérieur si vous ne le pouvez pas).

Certaines choses pour lesquelles j'utiliserais encore des déclencheurs

  • Suivi des champs "date_created" et "date_last_edited"
  • Insérer des "ID" (dans oracle, où il n'y a pas de champ d'identification automatique)
  • Garder l'historique des changements

Choses pour lesquelles vous ne voudriez pas utiliser de déclencheurs

  • règles / logique métier
  • tout ce qui se connecte en dehors de la base de données (par exemple, un appel de service Web)
  • Contrôle d'accès
  • Tout ce qui n'est pas transactionnel (tout ce que vous faites dans le déclencheur DOIT pouvoir être annulé avec la transaction)
Matthew Watson
la source
4

Oui, c'est sage. C'est en fait le but d'un déclencheur, d'effectuer les actions nécessaires après une opération d'insertion / mise à jour / suppression sur une table.

Vous devez prendre en compte le fait qu'un déclencheur dans MS SQL ne gérera pas chaque ligne séparément, mais gérera toutes les lignes de la transaction en cours à la fois. Donc, si une opération insère 10 lignes à la fois, vous devrez penser au code de votre déclencheur pour traiter toutes les lignes à la fois.

Marian
la source
1
Tant que le service qui remplit la base de données ne fait pas tout ce dont l'homme a besoin et tant qu'il ne peut pas changer le service (c'est mon sentiment après la description), et la question est ici sur DBA.SE, pas sur les programmeurs , Je dirai qu'un déclencheur bien documenté ne devrait pas poser de problème. Il a dit qu'il faisait certaines choses manuellement, donc le changement de code ne pouvait pas être impliqué d'après ce que je comprends ..
Marian
1
Dans ce cas, il peut s'agir de la seule option viable, ce qui ne rend pas la chose sage. La bonne chose à faire serait de repousser le développeur de l'application et de le faire insérer correctement dans les deux tables.
Matthew Watson
toux . Je vois où ça va. Désolé d'être clair dans ma question ci-dessus. J'ai la possibilité de changer le service d'intégration, même s'il ne me "appartient" pas. D'après ce que je peux lire, il est préférable de changer le service d'intégration et d'utiliser uniquement des déclencheurs pour les services d'audit / d'enregistrement d'historique.
Benny Skogberg
3

Les déclencheurs sont un outil puissant et, comme tout autre outil, vous devez être prudent lorsque vous les utilisez.

  1. Lorsque vous faites une erreur dans un déclencheur, les choses peuvent mal tourner drastiquement et à moins que vous exécutiez des traces, vous ne vous en rendrez pas compte ...

  2. Ils modifient / insèrent / suppriment «par magie» des données que l'utilisateur de la base de données (l'application actuelle / toute application future / un développeur effectuant une mise à jour unique) n'a pas réalisé / prévu.

Le gros problème est qu'après avoir créé le déclencheur, il n'est pas évident pour les autres développeurs / utilisateurs qu'un déclencheur est même là et ce qu'il fait.

Cela dit, ils sont un excellent outil pour maintenir l'intégrité de vos données et pour un véritable audit des modifications.

Vous devez vous demander si la logique que vous souhaitez mettre dans le déclencheur correspond le mieux aux applications ou à la base de données, en pesant les risques des deux côtés (que se passe-t-il si une nouvelle application arrive et ne l'applique pas) règle?)

Andrew Bickerton
la source