Dans SQL, il est possible de créer des traitements qui sont lancés selon des événements donnés ou des traitements indépendants, lancés à la demande.
Ces traitements permettent par exemple de :
- exécuter un contrôle de cohérence de la base lors de la modification/insertion/suppression d'enregistrements,
- faire un calcul de montant global dans une table de synthèse de données,
- lancer automatiquement la sauvegarde de plusieurs tables,
- etc.
Ces traitements sont faits avec :
- Triggers (déclencheur), traitement événementiels, liés à une et une seule table par trigger
- Procédures, traitement lancés à la demande, indépendantes des tables.
- etc.
Un trigger est un objet associé à une table et est déclenché lorsqu'un événement intrevient sur celle-ci. Un trigger contient des ordres sql avancés qui vont alors être éxécutés.
Exemple d'usage : Recalculer le montant du CA d'un client lors de l'enregistrement d'une facture ou placer un indicateur de promotion si le montant de ce CA dépasse une certaine valeur, etc. ...
Une procédure est un objet qui contient des instructions SQL et est lancé à la demande. Elle est indépendante d'une table en particulier
Avec cela, on entre dans le monde du PL/SQL, process language/SQL.
Avantages/inconvénients.
Pour les triggers, il n'y a pas photo, c'est plutôt bien mais ...
- Avantages :
- Permet d'efferctuer des contrôles de cohérence (inclusion/exclusion) et des claculs dépendant de transactions
- De n'autoriser certains trigger qu'à certains utilisateurs : gain de sécurité
- Inconvénients :
- On ne peut pas mettre plusieurs triggers sur la même transaction (/ex : before update)
- Il n'est donc possible de mettre que six triggers par table : (2*3, before/after update/delete/insert into)
- Les triggers compliqués sont à bannir à cause d'un maintenance nécessaire à chaque modification de structure.
Pour les procédures, idem, il y a du pour et du contre.
D'après le site dynamic-mess.com, on a :
- Avantages :
- Réduit les allers-retours entre le client et le serveur : donc gain de performance
- De n'autoriser certaines procédures qu'à certains utilisateurs : améliore donc la sécurité
- De s'assurer que certaines requêtes sensibles sont exécutées de la même manière quelque soit le language utilisé pour le développement du client
- Inconvénients :
- Ajoute de la charge au serveur SQL
- Certains traitements sont plus courts et plus simples si développés avec un language adapté
- La déclaration d'une procédure varie d'un SGBD à l'autre.
C'est pourquoi, les triggers et procédures sont parfois remplacés par des traitements effectués par l'application, malgré la rapidité de ces premiers et le gain de sécurité notable.