ProgrammationDéveloppeur Backend

Quelle est la différence entre les procédures stockées et les triggers en SQL ? Quand est-il préférable d'utiliser chacune de ces entités, et quelles erreurs les développeurs commettent-ils souvent en les mélangeant ?

Réussissez les entretiens avec l'assistant IA Hintsage

Réponse.

Procédures stockées (stored procedures) — blocs programmables qui sont appelés explicitement et peuvent accepter des paramètres, exécuter une logique métier complexe, gérer des transactions, retourner des ensembles de données ou des paramètres de sortie.

Triggers (triggers) — objets spéciaux qui se déclenchent "automatiquement" lors d'événements de modification des données (INSERT, UPDATE, DELETE), assurant l'exécution transparente d'une logique donnée lors de certaines actions sur une table.

Quand utiliser des procédures

  • Nécessité de traiter de gros volumes de données.
  • Besoin de contrôle explicite des transactions.
  • Doit retourner un résultat ou plusieurs ensembles de données.

Quand utiliser des triggers

  • Nécessité de garantir des vérifications ou mises à jour implicites lors de toute modification des données (par exemple, audit).
  • Besoin de mettre en œuvre des vérifications d'intégrité end-to-end.

Exemple de code

Procédure stockée :

CREATE PROCEDURE UpdateProductPrice @ProductID int, @NewPrice money AS BEGIN UPDATE Products SET Price = @NewPrice WHERE ProductID = @ProductID; END

Trigger :

CREATE TRIGGER trg_ProductsPriceChange ON Products AFTER UPDATE AS BEGIN INSERT INTO PriceAuditLog(ProductID, OldPrice, NewPrice, ChangeDate) SELECT i.ProductID, d.Price, i.Price, GETDATE() FROM inserted i JOIN deleted d ON i.ProductID = d.ProductID WHERE i.Price <> d.Price END

Question piège.

Q : Peut-on définir l'ordre d'exécution de plusieurs triggers AFTER sur une même table dans SQL Server avec les moyens standards ?

**R : Non, la norme SQL ne garantit pas l'ordre d'exécution des triggers AFTER d'une seule direction sur une même table. Si l'ordre est important, il faut les combiner en un seul.

Exemples d'erreurs réelles dues à une méconnaissance des subtilités du sujet.


Histoire

Dans une solution CRM pour prendre en charge la fonctionnalité d'historique des modifications, des triggers ont été utilisés. En raison de la forte charge des mises à jour massives, les enregistrements dans le log parvenaient avec retard et bloquaient les opérations "réelles", entraînant une indisponibilité temporaire du service.


Histoire

Un développeur a créé la logique de vérification des données non pas dans la procédure, mais dans le trigger, s'attendant à ce que les modifications soient visibles pour l'utilisateur instantanément. Ayant oublié que le trigger est "transparent", il a constaté que la logique métier était devenue peu évidente (de la "magie") et qu'il était difficile de la déboguer.


Histoire

Important : Souvent, une procédure est appelée à l'intérieur d'un trigger, ou un trigger depuis une procédure, ce qui conduit à la récursivité et à un dépassement de la limite de profondeur — par exemple, une insertion automatique entraîne le redémarrage du trigger via une procédure liée.