Version imprimable
Bonsoir,
J'ai vu dans des vidéos sur le SQL qu'il n(y a pas de trigger BEFORE sur SQL-Server.
Vu que cela existe dans MySQL par exemple, je suis surpris que ce ne soit pas le cas dans SQL-Server.
1ère question : Est-ce vraiment le cas ?
2ème question : dans ce cas pourquoi ?
Bonsoir Christophe,
Quand on constate un manque faut se demander ce que ça va couter de devoir s'en passer.
Quels sont les usages qui nécessiteraient d'avoir des trigger before ?
les déclencheurs BEFORE n'ont en pratique aucun intérêt puisque, par nature, les données ne sont pas encore intégrées.
Par conséquent :
1) pas de valeurs de la clé si elle est auto-incrémentée
2) pas de validation des contraintes
3) pas de ROLLBACK physique possible puisque la transaction effective n'a pas démarrée...
En revanche, il est possible d'utiliser des déclencheurs "INSTEAD OF" suivant ce que vous voulez faire...
Expliquez nous ce que vous voulez faire exactement et on vous guidera....
MySQL est une grosse merde en la matière et fait du n'importe quoi....
Pour information, c'est SQL Server (à l'époque sous Sybase) qui a inventé la notion de déclencheur.....
A +
Ca je peux entendre. Par contre j'en vois un : intercepter un insert et ne pas le faire (ou le faire) selon conditions définies par le trigger.Citation:
les déclencheurs BEFORE n'ont en pratique aucun intérêt puisque, par nature, les données ne sont pas encore intégrées.
Si je met de coté MySQL, Oracle, PostGreSQL gèrent les triggers BEFORE. Je me dit donc qu'il y a une raison
Vu que ça existe dans certains SGBDR je pourrais modifier la phrase en disant plutôt "les déclencheurs BEFORE ont en pratique peu d'intérêt", non ?
Merci pour le cours d'histoire.Citation:
Pour information, c'est SQL Server (à l'époque sous Sybase) qui a inventé la notion de déclencheur....
Pas de projet précis, juste de l'apprentissage.Citation:
Expliquez nous ce que vous voulez faire exactement et on vous guidera....
Le trigger "instead of" peut tout à fait faire l'insert ou faire tout autre chose selon les conditions définies dans son code ;)
Avec DB2 for Z/OS, un intérêt du TRIGGER "before" est de désactiver les autres déclencheurs, je ne sais pas si c'est aussi le cas avec MySQL.
Pour moi, un déclencheur se ramène à une contrainte procédurale.Citation:
Envoyé par escartefigue
Déjà, désactiver une contrainte me pose toujours question, même quand c'est "pour les perfs".
Normalement la désactivation porte sur la contrainte elle même, et non pas "pour celui qui la désactive".
Du coup, la maitrise du contexte devient un élément très important avant de se lancer dans ce genre de manœuvre ; et ce pour les contraintes standards.
Mais, si c'est pour désactiver de manière programmée, l'exécution de code qu'on maitrise, là je n'en vois pas l'utilité.
A part brouiller les pistes lors du débogage et faire chier ceux qui viennent après, je ne vois pas; Désolé.
Justement, parlons des conditionnelles qui sont accessibles lors de l'exécution du TRIGGER BEFORE.Citation:
Envoyé par chrtophe
Que peut-on faire exactement ?
Je ne comprend pas la question
Bonjour chrtophe,Citation:
Envoyé par chrtophe
J'imagine que c'est à propos de :
Chez Oracle les triggers BEFORE et AFTER comportent un paramètre supplémentaire FOR EACH ROW.Citation:
Envoyé par Michel.Priori
En fonction de ce paramètre les conditionnelles possibles sont différentes ; sans ces mots clés, pas d'accès aux données, donc pas de clause where sur une valeur du lot de données candidates.
Et même avec ces mots clé, tout n'est pas permis ; Oracle n'apprécie pas les mutants ;)
Si on remonte le fil de la conversation, la question n°2 qui demande pourquoi il n'existe pas de Trigger BEFORE sous SQL c'est vu objecter son utilité du fait du trigger INSTEAD OF.
Je reste sur ma demande initiale :
Citation:
Envoyé par Michel.Priori
Je suis un peu largué, SQL n'est pas mon domaine de compétences. J'en fait un peu mais du SQL simple.
De ce que je comprends, on peut se passer de BEFORE en utilisant INSTEAD OF. Mais dans ce cas, pourquoi des SGBD tels qu'Oracle ont implémenté BEFORE ce que n'a pas fait SQL-Server ? Pourquoi intégrer quelque chose qui n'a pas d’intérêt ?
Si c'est juste un choix "politique", je peux comprendre.
Ca c'est une question qui faut poser aux éditeurs.Citation:
Envoyé par chrtophe
Cependant voici quelques constatations :
* Oracle garanti une compatibilité du code. Une fois intégré, ça reste.
* MySQL n'a toujours pas implémenté les triggers instead of
* Postgres implemente de manière restreinte les triggers intead of
Citation:
INSTEAD OF triggers may only be defined on views, and only at row level; they fire immediately as each row in the view is identified as needing to be operated on.
Le seul intérêt des triggers BEFORE était de permettre d'ajouter une valeur de clé pour que l'insertion soit valide. Valeur de clé généré par une séquence (auto incrément indirect).Citation:
Envoyé par chrtophe
Or le premier SGBDR a intégrer l'auto incrément direct à été Sybase SQL server avec IDENTITY, rendant inutile les déclencheurs BEFORE.
Au sujet de l'intérêt d'activer ou désactiver d'autres déclencheurs par un déclencheur BEFORE, ce problème est aussi résolu par le fait que, dans SQL Server, dès l'origine, vous pouvez mettre autant de déclencheur AFTER que vous le souhaitez et piloter l'ordre d'exécution en choisissant celui qui sera le premier et/ou le dernier à l'aide de la procédure sp_settriggerorder
A +
C'est plus clair maintenant.
Merci à vous.