difference entre NOT DEFERRABLE et DEFERRABLE INITIALLY IMMEDIATE

Hello,

Je potasse l'ouvrage SQL de F. Brouard et je n'ai pas compris la différence entre une contrainte NOT DEFERRABLE et une contrainte DEFERRABLE INITIALLY IMMEDIATE.

"Pas déférable" c'est forcement immédiat... mais "deférable immédiat" c'est quoi

...la différence doit etre subtile...

Par contre je ne vois pas le rapport avec "déférer" alors que l'on parle bien de "différer" dans le temps... Encore un 2e mystère...

Sujet effectivement intéressant... Étant l'auteur, je me doit d'y répondre !

Le pilotage de la déferrabilité des contraintes procède en deux temps :

1) la contrainte peut être déférée ou ne peut pas l'être :

Code:

---

1 2 3 4

ALTER TABLE ... ADD CONSTRAINT ... NOT DEFERRABLE => n''est jamais déférable ALTER TABLE ... ADD CONSTRAINT ... DEFERRABLE => est déferrable (mais uniquement sur demande, pas par défaut, donc INITIALY IMMEDIATE) ALTER TABLE ... ADD CONSTRAINT ... DEFERRABLE INITIALY IMMEDIATE => (même que précédemment : est déferrable, mais uniquement sur demande, pas par défaut) ALTER TABLE ... ADD CONSTRAINT ... DEFERRABLE INITIALY DEFERRED => est déferrable et systématiquement déférée...

---

2) déferrement de la contrainte :

Code:

---

1 2 3 4

SET CONSTRAINTS <...> DEFERRED Impose que les contraintes mentionnées dans <...> et déferrables soient déférées SET CONSTRAINTS <...> IMMEDIATE Impose que les contraintes mentionnées dans <...> soit immédiatement appliquées

---

Le déferrement n'intervient que dans une transaction et si contraintes déférée il y a, alors la vérification de la contrainte sera effectuée au moment du COMMIT et non à chaque ordre SQL.

A noter : c'est le seul endroit dans SQL ou lançant un COMMIT on peut obtenir un ROLLBACK. En effet si une seule des contraintes déférée est violée alors la transaction est annulée...

Sur le terme déféré : le mot provient du jargon juridique et indique un transfert de responsabilité... Le prévenu a été déféré au parquet. Signifie que la police qui détenait le malfaiteur a confié à l'autorité judiciaire la responsabilité de l'individu en question. C'est bien ce qui se passe en définitive avec SQL. L'ordre SQL INSERT, UPDATE ou DELETE, délaisse l'application des contraintes dont il doit habituellement s'occuper pour en confier la vérification à la transaction. On voit bien qu'il y a transfert de responsabilité !... et non différemment dans le temps, même si l'un induit l'autre (quoique la notion d'atomicité des transactions devrait nous faire considérer que cette durée n'a pas de consistance...).

A +

Bonjour, merci pour cette réponse.

OK pour le INITIALLY DEFERRED : la contrainte agit au COMMIT de la transaction sur demande donc si pas demande ça a le même comportement que NOT DEFERRABLE : agit a l'instruction (ordre) sans attendre le COMMIT.

Je ne vois toutefois pas ce que l'on entend par "sur demande"... Est-ce à dire que d'une certaine manière on va dire à SQL : "ben sur ce coup-ci tu défères"... ? Si oui, de quelle façon ?

La demande étant le COMMIT, Si la transaction est explicite, c'est la commande SQL COMMIT que le développeur aura placé dans son code. C'est la transaction est implicite, le COMMIT est intégré à la commande SQL de mise à jour et dans ce cas la déferabilité n'a pas d'intérêt.

A +