NON DEFERRABLE versus DEFERRABLE INITIALEMENT IMMEDIATE

J'ai lu ceci à propos du mot-clé SQL DEFERRABLEdans Database Systems - The Complete Book .

Le dernier [NOT DEFERRABLE] est la valeur par défaut, et signifie que chaque fois qu'une instruction de modification de base de données est exécutée, la contrainte est vérifiée immédiatement après, si la modification peut violer la contrainte de clé étrangère.

Cependant, si nous déclarons qu'une contrainte est DEFERRABLE , nous avons la possibilité de la faire attendre qu'une transaction soit terminée avant de vérifier la contrainte.

Nous suivons le mot-clé DEFERRABLE soit INITIALLY DEFERRED soit INITIALLY IMMEDIATE . Dans le premier cas, la vérification sera reportée juste avant la validation de chaque transaction. Dans ce dernier cas, le contrôle sera effectué immédiatement après chaque relevé.

En quoi est-ce NOT DEFERRABLEdifférent de DEFERRABLE INITIALLY IMMEDIATE? Dans les deux cas, il semble que toutes les contraintes sont vérifiées après chaque déclaration individuelle.

Avec DEFERRABLE INITIALLY IMMEDIATEvous pouvez reporter les contraintes à la demande lorsque vous en avez besoin.

Ceci est utile si vous voulez normalement vérifier les contraintes au moment de l'instruction, mais par exemple, pour un chargement par lots, vous voulez reporter la vérification jusqu'au moment de la validation.

La syntaxe pour différer les contraintes est cependant différente pour les différents SGBD.

Avec, NOT DEFERRABLEvous ne pourrez jamais différer la vérification jusqu'au moment de la validation.

Mis à part les autres réponses (correctes), quand on parle de PostgreSQL , il faut dire que:

• avec NOT DEFERRABLE chaque ligne est vérifiée lors de l'insertion / mise à jour

• avec DEFERRABLE (actuellement IMMEDIATE ) toutes les lignes sont vérifiées à la fin de l'insertion / mise à jour

• avec DEFERRABLE (actuellement DEFERRED ) toutes les lignes sont vérifiées à la fin de la transaction

Il n'est donc pas correct de dire qu'une contrainte DEFERRABLE agit comme une contrainte NOT DEFERRABLE lorsqu'elle est définie sur IMMEDIATE.

Développons cette différence:

CREATE TABLE example(
    row integer NOT NULL,
    col integer NOT NULL,
    UNIQUE (row, col) DEFERRABLE INITIALLY IMMEDIATE
);

INSERT INTO example (row, col) VALUES (1,1),(2,2),(3,3);

UPDATE example SET row = row + 1, col = col + 1;

SELECT * FROM example;

Cela génère correctement:

Mais si nous supprimons l'instruction DEFERRABLE INITIALLY IMMEDIATE,

ERREUR: la valeur de clé en double enfreint la contrainte unique "example_row_col_key" DETAIL: Key ("row", col) = (2, 2) existe déjà. ********** Erreur **********

ERREUR: la valeur de clé en double viole la contrainte unique "example_row_col_key" État SQL: 23505 Détail: La clé ("row", col) = (2, 2) existe déjà.

ADDENDA (12 octobre 2017)

Ce comportement est en effet documenté ici , section "Compatibilité":

De plus, PostgreSQL vérifie immédiatement les contraintes d'unicité non reportables, pas à la fin de l'instruction comme le suggère la norme.

Outre l'évidence de pouvoir différer, la différence réside en fait dans les performances. S'il n'y avait pas de pénalité de performance, il ne serait pas nécessaire d'avoir la possibilité de choisir de différer ou non - toutes les contraintes seraient simplement reportables.

La pénalité des performances est liée aux optimisations que la base de données peut effectuer étant donné la connaissance de la manière dont les données sont restreintes. Par exemple, l'index qui est créé pour sauvegarder une contrainte unique dans Oracle ne peut pas être un index unique si la contrainte est reportable, car l'autorisation temporaire des doublons doit être autorisée. Cependant, si la contrainte n'est pas reportable, l'index peut être unique.

Je suis très en retard à la fête mais je voulais ajouter que - en décembre 2018 - seules deux bases de données que je connais (il y en a peut-être plus) offrent un certain niveau d'implémentation de cette fonctionnalité SQL standard :

Database    NOT DEFERRABLE  DEFERRABLE           DEFERRABLE 
                            INITIALLY IMMEDIATE  INITIALLY DEFERRED
----------  --------------  -------------------  ------------------
Oracle      N/A *1          Yes (default)        Yes
PostgreSQL  Yes (default)   Yes                  Yes
DB2         -               -                    -
SQL Server  -               -                    -
MySQL       -               -                    -
MariaDB     -               -                    -
SAP Sybase  -               -                    -
HyperSQL    -               -                    -
H2          -               -                    -
Derby       -               -                    -

* 1 Même si Oracle 12c accepte l' NOT DEFERRABLE état de contrainte , il l'ignore en fait et le fait fonctionner comme DEFERRABLE INITIALLY IMMEDIATE.

Comme vous le voyez, Oracle n'implémente pas le premier type ( NOT DEFERRABLE), et c'est pourquoi les développeurs utilisant Oracle (l'OP dans ce cas) peuvent être confus et considérer les deux premiers types comme équivalents.

Fait intéressant, Oracle et PostgreSQL ont un type par défaut différent. Cela a peut-être des implications sur les performances.

NOT DEFERRABLE - vous ne pouvez pas modifier la vérification des contraintes, oracle la vérifie après chaque instruction (c'est-à-dire directement après l'instruction insert).

DEFERRABLE INITIALLY IMMEDIATE - oracle vérifie la contrainte après chaque instruction. MAIS, vous pouvez le changer après chaque transaction (c'est-à-dire après la validation):

set constraint pk_tab1 deferred;