Wise utiliser déclencheur pour mettre à jour une autre table?

Question

J'ai une table Object qui est peuplée 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 les messages dans une autre table ObjectObjectGroup (ObjectId, ObjectGroupId) qui est nécessaire si Object.ObjectType ont une certaine valeur entière. Étant donné que le service d'intégration ne gère pas ce genre de mise à jour, je pense à ajouter un élément déclencheur à la table d'objet en pseudo-code serait la suivante:

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

Est-ce sage configuration, ou est-il une meilleure façon en termes de performance?

Answer 1

La plupart du temps Copier / coller ma réponse de cette Question sur stackoverflow

Triggers peut être très séduisante, quand vous commencez à les utiliser, ils semblent comme une balle magique pour toutes sortes de problèmes. Mais, ils font des choses « magique » se produire, si vous ne connaissez pas l'intérieur de la base de données, cela peut sembler des choses vraiment étranges se produisent (comme des insertions dans d'autres tableaux, les données d'entrée changeantes, etc.). Avant la mise en œuvre des choses comme déclencheur j'appliquer sérieusement envisager plutôt 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 pouvez pas).

Certaines choses que je toujours utiliser des déclencheurs pour

• Garder la trace de "date_created" et "date_last_edited" champs
• Insertion "ID" est (dans l'oracle, où il n'y a pas de champ id auto)
• Tenue historique des modifications

Les choses que vous ne voudrais pas utiliser des déclencheurs pour

• règles métier / logique
• tout ce qui se connecte à l'extérieur de la base de données (par exemple un appel webservice)
• Contrôle d'accès
• Tout ce qui est pas transactionnel (tout ce que vous faites dans la gâchette DOIT être en mesure de restaurer la transaction)

Answer 2

Oui, il est sage. Tel est l'objet d'un déclencheur en fait, d'effectuer des actions nécessaires après une insertion / mise à jour / opération de suppression sur une table.

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

Answer 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 peut aller les choses très sérieux problème et à moins que vous utilisez des traces que vous ne réaliserez pas ...

2. Ils font « comme par magie » changement / insertion / efface les données que l'utilisateur de la DB (la demande actuelle / toute application future / développeur faire une de mise à jour) n'a pas réalisé / l'intention.

Le gros problème est que, après avoir créé le déclencheur, il est pas évident à d'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 d'un véritable audit des changements.

Vous devez vous demander si la logique que vous voulez mettre dans la gâchette se trouve mieux avec l'application (s) ou dans le DB, pesant les risques des deux côtés (ce qui se passe si une nouvelle application arrive et n » t appliquer cette règle?)