Discussion :

[bankette]

Bonjour ,

Je souhaiterai connaitre les inconvénients (s'il y en a) du "defferable constraints".

En effet cet option n'est pas défini par défaut lorsque l'on défini un clé primaire :

Code :

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

SQL> CREATE TABLE lsc_t(x number constraint lsc_t_pk PRIMARY KEY deferrable initially deferred);

Il y a-t-il une raison pour que cette option, somme toutes très partique, ne soit pas définie par défaut sur toutes les clés primaires? Il y a-t-il des inconvénients a son utilisation?

Merci d'avance,

[Pomalaix]

Bonjour ,

Je souhaiterai connaitre les inconvénients (s'il y en a) du "defferable constraints".

En effet cet option n'est pas défini par défaut lorsque l'on défini un clé primaire :

Code :

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

SQL> CREATE TABLE lsc_t(x number constraint lsc_t_pk PRIMARY KEY deferrable initially deferred);

Il y a-t-il une raison pour que cette option, somme toutes très partique, ne soit pas définie par défaut sur toutes les clés primaires? Il y a-t-il des inconvénients a son utilisation?

Merci d'avance,

Bonjour

Comme vous le savez, par défaut une contrainte est vérifiée à la fin de l'opération modificative (UPDATE par exemple). Si vous reportez cette vérification à la fin de la transaction complète, cela veut dire que vous autorisez la violation de cette contrainte, et donc les incohérences qui en découlent, durant toute la durée de la transaction.
Certes, grâce à l'isolation, lesdites incohérences ne seront pas visibles des autres sessions, mais les autoriser c'est armer le pistolet pour se tirer une balle dans le pied...

[bankette]

Merci de ta réponse, je suis parfaitement conscient du fonctionnement et je ne pense l'utiliser que pour des transaction simple (un simple delete) mais sur des table possedant énormement de clé étrangère (un delete de 250 lignes prend environ 15 minutes !).

Ce que je souhaiterai savoir c'est il y a t il des effets de bord a ce paramétrage, est ce que cela peut avoir des influence sur les performances général de la BDD, il y a t il des opération qui ne sont plus permises? En gros il y a t il un coté obscure au defferable constraint ?

[mnitu]

...un delete de 250 lignes prend environ 15 minutes ...

Si c'est vrai probablement qu'il faut vérifier l'opportunité d'avoir des indexes sur les clés étrangères. Faite une trace SQL étendue pour savoir plus.
De toute façon defferable ou pas la contrainte sera vérifié.

[laurentschneider]

à mon avis, si tu as DEFERRABLE INITIALLY IMMEDIATE, alors le fonctionnement est le même que NOT DEFERRABLE

La différence est que avec NOT DEFERRABLE, l'utilisateur qui n'a pas ALTER ANY TABLE ne peut pas modifier se fonctionnement. Donc en quelque sorte l'inconvénient de mettre toujours DEFERRABLE INITIALLY IMMEDIATE se limite à une question applicative. Il se pourrait par exemple qu'un TRIGGER soit lancé alors que la ligne sera rejettée lors du COMMIT

[laurentschneider]

bon, par contre d'avoir DEFERRABLE INITIALLY DEFERRED, ça change fondamentalement le fonctionnement de l'application

[laurentschneider]

tu auras aussi plus de rollback en cas de violation lors du commit d'une grosse transaction

[bankette]

Il se pourrait par exemple qu'un TRIGGER soit lancé alors que la ligne sera rejettée lors du COMMIT

Ceci peut etre très génant ! Est ce que cela veut dire que un trigger pourra etre déclencher par un delete dans une table1, modifier d'autre table ou autre chose, mais seules les modifications de la table1 seront rollbacké, c'est a dire que toutes les modifications faites pas le trigger seront validés?

[mnitu]

Non ! Sauf bien sûr mauvaise utilisation du pragma autonomous transaction

@Laurent
Dire "si tu as DEFERRABLE INITIALLY IMMEDIATE, alors le fonctionnement est le même que NOT DEFERRABLE" c'est un peu confuse, ne pense tu ?

[laurentschneider]

@mnitu OK, je reformule

avec DEFERRABLE INITIALLY IMMEDIATE et avec NOT DEFERRABLE, la validation est faite pour chaque statement.

La différence est que, au besoin, on peut déferrer la contrainte, par exemple pour un batch. Mais dans le cas où la contrainte est IMMEDIATE, le "déferrable" ne joue aucun effet.

Donc il n'y a pas vraiment d'inconvénient à avoir DEFERRABLE INITIALLY IMMEDIATE plutôt que NOT DEFERRABLE ... sauf bien sûr si l'on veut empêcher les utilisateurs de faire SET CONSTRAINTS ALL DEFERRED

C'est plus clair

[bankette]

Oui c'est très clair !

cependant si cela ne présente aucun inconvénient pourquoi le defferrable constraint n'est pas défini par défaut pour toutes les clés? Ma question peut paraitre un peu bete, mais pourquoi une option qui a priori ne presente aucun inconvénient n'est pas définie systématiquement et doit etre ajouter a chaque création de clé?

Merci,

[mnitu]

Je pense que c’est historique : quand Oracle a ajouté les contraints dans la version 7 elles n’étaient pas deferrable.

[bankette]

OK, merci beaucoup pour vos réponses !!