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

[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?