Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
SQLpro
Le 22/12/2010 15:05, Etienne a écrit :
salut.
bon ben tout est dans le titre. J'ai un trigger sur le ON UPDATE.
sauf que parfois je modifie un enregistrement et que je suis absolument sur que l'execution du trigger est inutile.
Y a t-il un moyen d'executer une requetes sans executer les trigger associé a la table ?
Merci Etienne
oui, en gérant une transaction qui supprime les triggers concernés et les replacent après exécution de la requête, le tout au niveau d'isolation SERIALIZABLE.
A +
-- Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66 Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence Audit, conseil, expertise, formation, modélisation, tuning, optimisation *********************** http://www.sqlspot.com *************************
Le 22/12/2010 15:05, Etienne a écrit :
salut.
bon ben tout est dans le titre.
J'ai un trigger sur le ON UPDATE.
sauf que parfois je modifie un enregistrement et que je suis absolument
sur que l'execution du trigger est inutile.
Y a t-il un moyen d'executer une requetes sans executer les trigger
associé a la table ?
Merci
Etienne
oui, en gérant une transaction qui supprime les triggers concernés et
les replacent après exécution de la requête, le tout au niveau
d'isolation SERIALIZABLE.
A +
--
Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
bon ben tout est dans le titre. J'ai un trigger sur le ON UPDATE.
sauf que parfois je modifie un enregistrement et que je suis absolument sur que l'execution du trigger est inutile.
Y a t-il un moyen d'executer une requetes sans executer les trigger associé a la table ?
Merci Etienne
oui, en gérant une transaction qui supprime les triggers concernés et les replacent après exécution de la requête, le tout au niveau d'isolation SERIALIZABLE.
A +
-- Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66 Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence Audit, conseil, expertise, formation, modélisation, tuning, optimisation *********************** http://www.sqlspot.com *************************
Etienne
Le 01/01/2011 09:55, SQLpro a écrit :
Le 22/12/2010 15:05, Etienne a écrit : oui, en gérant une transaction qui supprime les triggers concernés et les replacent après exécution de la requête, le tout au niveau d'isolation SERIALIZABLE.
Heu ouai. C'est pas un peu lourd dingue comme solution? je vais chercher une méthode un poil plus légère.
Etienne
Le 01/01/2011 09:55, SQLpro a écrit :
Le 22/12/2010 15:05, Etienne a écrit :
oui, en gérant une transaction qui supprime les triggers concernés et
les replacent après exécution de la requête, le tout au niveau
d'isolation SERIALIZABLE.
Heu ouai. C'est pas un peu lourd dingue comme solution?
je vais chercher une méthode un poil plus légère.
Le 22/12/2010 15:05, Etienne a écrit : oui, en gérant une transaction qui supprime les triggers concernés et les replacent après exécution de la requête, le tout au niveau d'isolation SERIALIZABLE.
Heu ouai. C'est pas un peu lourd dingue comme solution? je vais chercher une méthode un poil plus légère.
Etienne
SQLpro
Le 03/01/2011 09:33, Etienne a écrit :
Le 01/01/2011 09:55, SQLpro a écrit :
Le 22/12/2010 15:05, Etienne a écrit : oui, en gérant une transaction qui supprime les triggers concernés et les replacent après exécution de la requête, le tout au niveau d'isolation SERIALIZABLE.
Heu ouai. C'est pas un peu lourd dingue comme solution? je vais chercher une méthode un poil plus légère.
Etienne
Il n'y pas d'autres solution, si vous voulez rester consistant !
En revanche il est sans doute possible de coder dans le trigger cette "non exécution". Par exemple dans SQL Server il est possible de tester si telle ou telle colonne a été mise à jour afin de lancer ou non le code du trigger. J'ai pas vu cela chez PG....
A +
-- Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66 Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence Audit, conseil, expertise, formation, modélisation, tuning, optimisation *********************** http://www.sqlspot.com *************************
Le 03/01/2011 09:33, Etienne a écrit :
Le 01/01/2011 09:55, SQLpro a écrit :
Le 22/12/2010 15:05, Etienne a écrit :
oui, en gérant une transaction qui supprime les triggers concernés et
les replacent après exécution de la requête, le tout au niveau
d'isolation SERIALIZABLE.
Heu ouai. C'est pas un peu lourd dingue comme solution?
je vais chercher une méthode un poil plus légère.
Etienne
Il n'y pas d'autres solution, si vous voulez rester consistant !
En revanche il est sans doute possible de coder dans le trigger cette
"non exécution".
Par exemple dans SQL Server il est possible de tester si telle ou telle
colonne a été mise à jour afin de lancer ou non le code du trigger.
J'ai pas vu cela chez PG....
A +
--
Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
Le 22/12/2010 15:05, Etienne a écrit : oui, en gérant une transaction qui supprime les triggers concernés et les replacent après exécution de la requête, le tout au niveau d'isolation SERIALIZABLE.
Heu ouai. C'est pas un peu lourd dingue comme solution? je vais chercher une méthode un poil plus légère.
Etienne
Il n'y pas d'autres solution, si vous voulez rester consistant !
En revanche il est sans doute possible de coder dans le trigger cette "non exécution". Par exemple dans SQL Server il est possible de tester si telle ou telle colonne a été mise à jour afin de lancer ou non le code du trigger. J'ai pas vu cela chez PG....
A +
-- Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66 Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence Audit, conseil, expertise, formation, modélisation, tuning, optimisation *********************** http://www.sqlspot.com *************************
WebShaker
Le 03/01/2011 23:29, SQLpro a écrit :
Il n'y pas d'autres solution, si vous voulez rester consistant !
En revanche il est sans doute possible de coder dans le trigger cette "non exécution". Par exemple dans SQL Server il est possible de tester si telle ou telle colonne a été mise à jour afin de lancer ou non le code du trigger. J'ai pas vu cela chez PG....
Oui j'ai pensé a cette solution. le problème est que le test additionnel de mon trigger va peut être me faire gagner du temps lorsque je ne veux pas l'exécuter (encore que ce n'est pas sur) mais va m'en faire perdre dans les autres cas.
J'ai envisagé une autre solution sans doute moins élégante et pourtant surement plus efficace: créer une table fille (héritée) de ma table et utiliser cette table fille pour les requêtes ne nécessitant pas l'exécution des triggers.
Reste à tester (tout de même)...
Etienne
PS: je suis content de vous apprendre quelques chose ;) pour une fois. (enfin si toute fois ca marche)
Le 03/01/2011 23:29, SQLpro a écrit :
Il n'y pas d'autres solution, si vous voulez rester consistant !
En revanche il est sans doute possible de coder dans le trigger cette
"non exécution".
Par exemple dans SQL Server il est possible de tester si telle ou telle
colonne a été mise à jour afin de lancer ou non le code du trigger.
J'ai pas vu cela chez PG....
Oui j'ai pensé a cette solution.
le problème est que le test additionnel de mon trigger va peut être me
faire gagner du temps lorsque je ne veux pas l'exécuter (encore que ce
n'est pas sur) mais va m'en faire perdre dans les autres cas.
J'ai envisagé une autre solution sans doute moins élégante et pourtant
surement plus efficace:
créer une table fille (héritée) de ma table et utiliser cette table
fille pour les requêtes ne nécessitant pas l'exécution des triggers.
Reste à tester (tout de même)...
Etienne
PS: je suis content de vous apprendre quelques chose ;) pour une fois.
(enfin si toute fois ca marche)
Il n'y pas d'autres solution, si vous voulez rester consistant !
En revanche il est sans doute possible de coder dans le trigger cette "non exécution". Par exemple dans SQL Server il est possible de tester si telle ou telle colonne a été mise à jour afin de lancer ou non le code du trigger. J'ai pas vu cela chez PG....
Oui j'ai pensé a cette solution. le problème est que le test additionnel de mon trigger va peut être me faire gagner du temps lorsque je ne veux pas l'exécuter (encore que ce n'est pas sur) mais va m'en faire perdre dans les autres cas.
J'ai envisagé une autre solution sans doute moins élégante et pourtant surement plus efficace: créer une table fille (héritée) de ma table et utiliser cette table fille pour les requêtes ne nécessitant pas l'exécution des triggers.
Reste à tester (tout de même)...
Etienne
PS: je suis content de vous apprendre quelques chose ;) pour une fois. (enfin si toute fois ca marche)
Sebastien Lardiere
On 01/03/2011 11:29 PM, SQLpro wrote:
Il n'y pas d'autres solution, si vous voulez rester consistant !
En revanche il est sans doute possible de coder dans le trigger cette "non exécution". Par exemple dans SQL Server il est possible de tester si telle ou telle colonne a été mise à jour afin de lancer ou non le code du trigger. J'ai pas vu cela chez PG....
Dans la verion 9.0, ça existe :
For UPDATE triggers, it is possible to specify a list of columns using this syntax:
Dans les versions antérieures, il suffit de le coder, ça n'est pas compliqué, ni si couteux.
if new.col1 != old.col2 then ...
C'est consistant, et ça n'est pas si lent. Là, c'est une version simpliste, mais dans l'ensemble, ça fonctionne.
-- Sébastien
On 01/03/2011 11:29 PM, SQLpro wrote:
Il n'y pas d'autres solution, si vous voulez rester consistant !
En revanche il est sans doute possible de coder dans le trigger cette
"non exécution".
Par exemple dans SQL Server il est possible de tester si telle ou telle
colonne a été mise à jour afin de lancer ou non le code du trigger.
J'ai pas vu cela chez PG....
Dans la verion 9.0, ça existe :
For UPDATE triggers, it is possible to specify a list of columns using
this syntax:
Il n'y pas d'autres solution, si vous voulez rester consistant !
En revanche il est sans doute possible de coder dans le trigger cette "non exécution". Par exemple dans SQL Server il est possible de tester si telle ou telle colonne a été mise à jour afin de lancer ou non le code du trigger. J'ai pas vu cela chez PG....
Dans la verion 9.0, ça existe :
For UPDATE triggers, it is possible to specify a list of columns using this syntax:
Dans les versions antérieures, il suffit de le coder, ça n'est pas compliqué, ni si couteux.
if new.col1 != old.col2 then ...
C'est consistant, et ça n'est pas si lent. Là, c'est une version simpliste, mais dans l'ensemble, ça fonctionne.
Oui. En fait il faudrait connaitre le coup de déclenchement d'un trigger qui ne fait rien. Bon là on chipote, mais l'idée c'est simplement de gagner un poil de temps lors que c'est possible.
Etienne
Le 04/01/2011 10:08, Sebastien Lardiere a écrit :
On 01/03/2011 11:29 PM, SQLpro wrote:
Dans la verion 9.0, ça existe :
For UPDATE triggers, it is possible to specify a list of columns using
this syntax:
Dans les versions antérieures, il suffit de le coder, ça n'est pas
compliqué, ni si couteux.
if new.col1 != old.col2 then
...
C'est consistant, et ça n'est pas si lent. Là, c'est une version
simpliste, mais dans l'ensemble, ça fonctionne.
Oui. En fait il faudrait connaitre le coup de déclenchement d'un trigger
qui ne fait rien.
Bon là on chipote, mais l'idée c'est simplement de gagner un poil de
temps lors que c'est possible.
Dans les versions antérieures, il suffit de le coder, ça n'est pas compliqué, ni si couteux.
if new.col1 != old.col2 then ...
C'est consistant, et ça n'est pas si lent. Là, c'est une version simpliste, mais dans l'ensemble, ça fonctionne.
Oui. En fait il faudrait connaitre le coup de déclenchement d'un trigger qui ne fait rien. Bon là on chipote, mais l'idée c'est simplement de gagner un poil de temps lors que c'est possible.
