Discussion :

[new_wave]

Bonjour,
Je viens delire ces propos à propos des triggers de base de données

A la différence d'une contrainte d'intégrité, un déclencheur de base de données défini pour appliquer une règle d'intégrité ne vérifie pas les données
chargées dans une table. Il est donc conseillé d'utiliser des déclencheurs de base de données uniquement lorsqu'une règle d'intégrité ne peut pas
être appliquée par des contraintes d'intégrité.

J'avoue que je ne comprends pas grand chose à cette phrase.
Pouvez vous me dire pourquoi un trigger défini pour appliquer une règle d'intégrité ne vérifie pas les données chargées dans une table.
N'est ce pas là le rôle d'une contrainte d'intégrité?
Pouvez-vous me donner un exemple, je vous en remercie beaucoup, je pense que cela me parlera plus.

Mercie beaucoup à vous.
Cordialement.
new_wave

[mnitu]

Difficile à dire ce que la personne qui a dit voulait dire et ce que la personne qui a noté a compris de ces affirmations. Probablement qu'il s'agit de ces propos:
How Triggers and Constraints Differ

[Mohamed.Houri]

Utiliser un trigger pour valider une contrainte d'intégrité est une erreur fatale dans un environnement multi-user. Comme les selects ne bloquent pas les update/delete/insert/merge et vice versa (read consistency concept), lorsque vous vérifiez une contrainte d'intégrité dans un environnement concurrent les modifications de l'un peuvent ne pas être visibles par l'autre et la contrainte sera mal validée. Si vous insistez à utiliser le trigger dans ce contexte vous devriez alors sérialiser l'accès à votre table via un explicit "lock table". Cela rendrait votre application non performante et uni-user!!!

Je vous invite à lire ce lien pour plus de détails:

http://www.oracle.com/technetwork/is...om-101055.html

[Yanika_bzh]

Vrai pour les contraintes d'intégrité relationnelle, mais moins vrai pour les contraintes d'intégrité par condition booléenne (CHECK)

[mnitu]

Utiliser un trigger pour valider une contrainte d'intégrité est une erreur fatale dans un environnement multi-user. Comme les selects ne bloquent pas les update/delete/insert/merge et vice versa (read consistency concept), lorsque vous vérifiez une contrainte d'intégrité dans un environnement concurrent les modifications de l'un peuvent ne pas être visibles par l'autre et la contrainte sera mal validée. Si vous insistez à utiliser le trigger dans ce contexte vous devriez alors sérialiser l'accès à votre table via un explicit "lock table". Cela rendrait votre application non performante et uni-user!!!

Je vous invite à lire ce lien pour plus de détails:

http://www.oracle.com/technetwork/is...om-101055.html

Vous allez un peu trop vite et l’exemple du Tom Kyte parle de quelque chose d’assez particulière. Lisez aussi: Triggers for Ensuring Referential Integrity

[Mohamed.Houri]

Vous allez un peu trop vite et l’exemple du Tom Kyte parle de quelque chose d’assez particulière. Lisez aussi: Triggers for Ensuring Referential Integrity

Marius,

Preferez vous une simple contrainte étrangère

Code :

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

1
2
3
 
alter table emp add constraint emp_fk foreign key(deptno) references dept;
create index emp_fk_ind on emp(deptno);

à un trigger avec plusieurs lignes de code ou de toute façons nous sommes obligés de sérialiser les modifications

Code :

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

1
2
3
4
5
 
CURSOR Dummy_cursor (Dn NUMBER) IS
    SELECT Deptno FROM dept
    WHERE Deptno = Dn
    FOR UPDATE OF Deptno;

C'est pour cela que je préfère toujours quand cela est possible d'utiliser les contraintes d'intégrité (check, fk, etc..) au lieu et place des triggers.

http://asktom.oracle.com/pls/asktom/...53473305799476

[Rams7s]

C'est pour cela que je préfère toujours quand cela est possible d'utiliser les contraintes d'intégrité (check, fk, etc..) au lieu et place des triggers.

De 1 c'est le role du SGBDR d'assurer ce genre de chose avec les contraintes. Sinon on peut prendre un NoSQL.
Et pis oracle utilise les contraintes dans le CBO, donc c'est mieux de les utiliser.

[Waldar]

Et pis oracle utilise les contraintes dans le CBO, donc c'est mieux de les utiliser.

Pas toutes malheureusement, à ma connaissance et sur 11gR1 il n'utilise pas les contraintes CHECK (contrairement au concurrent de chez Microsoft) !

Ou alors avec une astuce que je n'ai pas trouvée !

[mnitu]

Marius,

Preferez vous une simple contrainte étrangère

...

Ce n’est pas ça que je vous ai dit mais simplement qu’il y des cases qui ne sont pas gérable avec les contraints.

[pachot]

Bonjour,

Vous allez un peu trop vite et l’exemple du Tom Kyte parle de quelque chose d’assez particulière. Lisez aussi: Triggers for Ensuring Referential Integrity

Oui, les triggers présentés dans Triggers for Ensuring Referential Integrity fonctionnent, mais c'est une catastrophe pour un système multi-user.
L'exemple 'Foreign Key Trigger for Child Table' empêche de faire 2 inserts en même temps lorsqu'ils ont le même parent. Les inserts seront sérialisés.

En fait, coder de l'intégrité qui fait référence à autre chose que l'enregistrement en cours obligera la plupart du temps à vérouiller très large.

Cordialement,
Franck.

[Pomalaix]

...
Je viens delire ces propos à propos des triggers de base de données

Et si veut on les lire nous aussi, de quel site Web ou livre s'agit-il ?