Discussion :

[monsurf]

Bonjour,

J'aimerais créer un trigger sur une table PRODUIT.
le trigger doit se declencher quand il ya une insertion dans cette table PRODUIT pour un certain Client avec id_client=XXXX.
jusque là tout parait simple.
Le souci est le suivant: dans cette table PRODUIT il ya des milliers d'insertions qui se font par jour, donc la question de performance surgit du coup...
est ce que le fait d'avoir un trigger sur cette table va t il augmenter le temps d'insertion dans la table?!
je pose la question, simplement car je sais pas comment fonctionne le mecanisme des declencheurs...
merci pour vos explications!

[kagemaru]

bonsoir,

le trigger augmente en effet les temps d'insertion mais de manière très sensible.
Tout dépend de la complexité du trigger. Si c'est simplement une mise à jour d'une autre table (un simple insert, update, delete), la performance est très peu affectée.
Sur les insertions de masses, la différence peut se faire sentir également.
Il faut bien garder en tête que les triggers doivent rester les plus simples possibles, sans règle de gestion complexes, curseurs etc.

[SQLpro]

effectivement un trigger rallonge de manière sensible les temps d'insertion. Il y a cepandant différents moyens de minimiser ces temps :
1) commiter la transaction le plus tôt possible : un trigger étant à l'intérieur de la transaction, la commiter au plus tôt permet de minimiser les temps de pose des verrous
2) ne lancer le code que si nécessaire. Si seule certaines colonnes sont visées dans le trigger alors tester leur évolution. Si elles n'ont pas évoluées alors quitter le code. Ceci peut se faire à l'aide des fonctions UPDATE() et COLUMNS_UPDATED()

A +

[monsurf]

Bonjour et merci pour vos réponses.

en fait, il ya plusieurs façons pour faire ce que je voudrais realiser.

mon cas est le suivant:
chaque jours il ya des enregistrements de produits pour certains clients.
on va dire 1000 insertions dans la table Produit.
ici, j'ai le cas d'un client pour lequel il ne faudrais pas accepter un certain produit...
-donc j'ai la possibilité de faire des filtre dans les procedures d'insertion, et tester à chaque fois sur le ID_Client avant de faire le booking (il ya aussi moyen de le faire avec une table qui contient une liste de ID_Client, genre une liste noire...)
mais cette solution risque de prendre plus de temps de developpement.
-l'autre possiblité, et c'est la raison de cette discussion, est de faire un trigger sur la table Produit, donc le trigger devrait fonctionner comme ceci:
apres insertion, je teste si ID_Client=XXX, si oui, faire un update, voir un delete de la ligne inserée...
l'avanatage ici c'est que c'est facile est rapide au niveau de la programmation, mais il y aurait le trigger qui sera là à chaque insetion, en sachant qu'il ne sera pas declenché tres souvent (peut etre une seule fois puis c'est tout).

voila, est ce que c'est toujours une bonne idée d'utiliser des triggers dans mon cas?! ou peut etre vous avez d'autres idées plus intelligentes?!

Merci beaucoup

[SQLpro]

Le trigger sera TOUJOURS déclenché !!! C'est à cela qu'il sert. De plus il est ensembliste donc porte sur beaucoup de données. En sus il perturbe les transactions. Par exemple la valeur de @@IDENTITY risque de ne pas être la même avec le trigger.

Contrairement à ce que vous dites, il y a fort à parier qu'il est moins couteux de développer une proc stock, éventuellement avec une table de clients douteux, que de faire cela dans un trigger.

Quand à la problématique des performances : un trigger à un coût relatif de 1000 là ou une proc stock sea de 1...

A +

[monsurf]

Merci encore pour votre réponse.

pour ce qui de la programmation d'un filtre en utilisant une table de clients douteux, ca me met devant le probleme suivant:
les sources desquelles peuvent venir les demandes du client X sont tres different... il peut faire un booking via internet, via des formulaires offline (scanné et lu par des programmes automatique, puis booké avec des procedures d'importations)... le booking pourrait meme se faire via un appel Hotline, donc manuellent à l'aide d'une interface utilisateur liée à la base de donnée...
donc si j'opte pour une solution autre que le trigger, je risque de devoir programmer pour chaqu'une des sources citées plus haut... en esperant ne pas avoir oublié d'autres......

en attendant d'autres idées, je vais proposer les deux solutions, en indiquant les avantages et les incovenients de chacune... puis c'est au chef de decider... meme si en fin de compte il s'en fout... il veut juste voir que ca marche

[SQLpro]

Si vous avez tant de difficulté à réaliser ce traitrement par de simple requête c'est qu'il est probable que votre modèle soit mal modélisé.

Une modèle de données doit pemettre de traiter les process de la manière la plus simple qui soit. Si ces traitements s'avèrent compliqué, c'est tout simplement que le modèle est inadapté. Et un modèle inadapté c'est toujours des performances médiocres à lamentables.

Lisez les articles que j'ai écrit à ce sujet :
http://www.sqlspot.com/Voulez-vous-optimiser-votre.html

A +

[monsurf]

Bonjour,

ce traitement pourrait etre facilement effectué par des requetes simples, le probleme c'est qu'il faudrait faire plusieur requete simple dans plusieurs endroit pour etre sûr qu'on traite tout les cas...

vous avez raison, ceci est dû au model mal conçu (je dirais pas de la base de donnée, mais plutot de l'application qui gere la bdd)...

au depart, il n y avait qu'un seul moyen de faire des booking dans la table Produit... et ce via une application, manuellement par un utilisateur, donc un INSERT d'une seul ligne dans la table Produit.
puis, il ya eu les cartes postales, on recoit tout les jours des milliers de cartes, qui contiennent (Numero Client, Numero Produit)... ces cartes sont scannées et enregistrés de maniere automatique... puis il ya un process d'IMPORT de donnée qui fait les insertions (milliers)...
et maintenant il ya aussi la possiblité que les clients puissent booker directement via internet... biensur, le booking ne touche pas directement la table Produit de base, ca passe via une table produit intermediaire... apres il ya encore une autre procedure d'IMPORTpour inserer ces "online bookings"...

donc si vous voyer, la base de donnée en elle meme n'est pas tres compliqué, c'est plutot le programme qui la gere qui se complique au fûr et à mesure que les besoins du client augmentent