Discussion :

[Titouf]

Bonjour,
Nous avons 3 tables avec 3 colonnes qui doivent être renseignées par les mêmes valeurs. Or nous devons remplir, ces 3 tables par notre progiciel l'une après l'autre, si nous n'en oublions pas une...
Y a t il une méthode de mettre à jour les 2 tables lorqsqu'on remplit la première? Je pensais par un trigger?
Qu'est ce que vous en pensez? Si oui, Auriez vous un exemple de code d'un trigger?
Merci, bye...

[SQLpro]

Quelque chose comme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
CREATE TRIGGER MonTrigger
ON Table1
FOR AFTER INSERT
 
BEGIN
 
INSERT INTO TABLE 2
SELECT *
FROM   NEW
 
INSERT INTO TABLE 3
SELECT *
FROM   NEW
 
END

La syntaxe dépend du SGBDR.

A +

[Titouf]

Merci, il s'agissait d'ORACLE.

Je vais essayer de faire cela...

Mais j'aimerais savoir quels sont les avantages et désavantages à utiliser un trigger?

Cette question est simplement pour que je puisse justifier de l'utilisation de cette synthaxe auprès de mes supérieurs.

Mercie d'avance.

Thierry
http://progibank.free.fr

[SQLpro]

Le terme avantage ou désavantage n'a pas de sens dans le domaine du fonctionnel...

Quel est l'avantage de s'arrêter au feu rouge ou de la passer ?

Encore pourrait parler d'avantage par rapport à un autre moyen...


A +

[Xo]

Mais j'aimerais savoir quels sont les avantages et désavantages à utiliser un trigger?

Coder ce genre d'automatismes dans un trigger permet de centraliser le traitement dans la BDD : ceci est fort intéressant quand il existe différents interfaces utilisateurs qui accèdent aux mêmes données.

[fregolo]

Bonjour,

Le code contenu dans un trigger pourrait aussi se trouver dans une procédure stockée.
Y a-t-il des différences en termes de performance ?
Existe-t-il des règles ou recommendations pour écrire le code dans un trigger plutôt que dans une procédure ?

Merci d'avance

[SQLpro]

Le code contenu dans un trigger pourrait aussi se trouver dans une procédure stockée.
Y a-t-il des différences en termes de performance ?
Existe-t-il des règles ou recommendations pour écrire le code dans un trigger plutôt que dans une procédure ?

Vous êtes sur la bonne voie ! Evidemment qu'il faut passer par une SP. Mieux dans ce cas interdisez l'utilisation directe des ordres INSERT, UPDATE et DELETE par une gestion fine des privilèges et réalisez les par des SP qui peuvent préparer les données. Ce sera mille fois moins couteux et bien plus proche de la notion objet.

A +

[fregolo]

Merci de votre réponse

Donc les triggers existent, mais ne sont pas recommandés dans la pratique.
Sont-ils alors vraiment sans intérêt ?

[SQLpro]

Donc les triggers existent, mais ne sont pas recommandés dans la pratique.

non, je dirais simplement que si d'autres possibilité existe autant le faire sans triggers.

Sont-ils alors vraiment sans intérêt ?

non car ils permettent d'implémenter les ASSERTIONS SQL plus finement que la norme ne l'a prévu mais au moyen de plus de code.
Bref ils permettent de valider des contraintes plus complexes que celle nativement proposées par SQL.
Exemple : exclusion dans un héritage de données, non relation, unicité transverse....

A +

[fregolo]

Merci beaucoup de votre réponse !