NO DEFERRABLE versus DEFERRABLE INICIALMENTE INMEDIATO

Leí esto sobre la palabra clave SQL DEFERRABLEen Database Systems - The Complete Book .

El último [NO DEFERRABLE] es el predeterminado y significa que cada vez que se ejecuta una instrucción de modificación de la base de datos, la restricción se verifica inmediatamente después, si la modificación podría violar la restricción de clave externa.

Sin embargo, si declaramos que una restricción es DEFERRABLE , entonces tenemos la opción de hacer que espere hasta que se complete una transacción antes de verificar la restricción.

Seguimos la palabra clave DEFERRABLE por cualquiera INICIALMENTE DIFERIDO o INICIALMENTE INMEDIATA . En el primer caso, la verificación se aplazará justo antes de que se confirme cada transacción. En este último caso, la verificación se realizará inmediatamente después de cada extracto.

¿En qué se NOT DEFERRABLEdiferencia de DEFERRABLE INITIALLY IMMEDIATE? En ambos casos, al parecer, las restricciones se verifican después de cada declaración individual.

Con DEFERRABLE INITIALLY IMMEDIATEpuede diferir las restricciones bajo demanda cuando lo necesite.

Esto es útil si normalmente desea verificar las restricciones en el momento de la declaración, pero, por ejemplo, una carga por lotes desea posponer la verificación hasta el momento de la confirmación.

Sin embargo, la sintaxis de cómo diferir las restricciones es diferente para los distintos DBMS.

Con NOT DEFERRABLEusted nunca podrá aplazar la verificación hasta el momento del compromiso.

Aparte de las otras respuestas (correctas), cuando se habla de PostgreSQL , se debe decir que:

• con NOT DEFERRABLE cada fila se marca en el momento de la inserción / actualización

• con DEFERRABLE (actualmente INMEDIATO ) todas las filas se verifican al final de la inserción / actualización

• con DEFERRABLE (actualmente DEFERRED ) todas las filas se verifican al final de la transacción

Por lo tanto , no es correcto decir que una restricción DEFERRABLE actúa como una NO DEFERRABLE cuando se establece en INMEDIATO.

Desarrollemos esta diferencia:

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;

Esto produce correctamente:

Pero si eliminamos la instrucción DEFERRABLE INICIALMENTE INMEDIATA,

ERROR: el valor de clave duplicado viola la restricción única "example_row_col_key" DETALLE: La clave ("fila", col) = (2, 2) ya existe. ********** Error **********

ERROR: el valor de clave duplicado viola la restricción única "example_row_col_key" Estado SQL: 23505 Detalle: La clave ("fila", col) = (2, 2) ya existe.

ADENDA (12 de octubre de 2017)

De hecho, este comportamiento está documentado aquí , sección "Compatibilidad":

Además, PostgreSQL verifica las restricciones de unicidad no diferibles inmediatamente, no al final de la declaración como sugiere el estándar.

Aparte de lo obvio de poder aplazar, la diferencia es en realidad el rendimiento. Si no hubiera una penalización de desempeño, entonces no habría necesidad de tener la opción de elegir diferible o no; todas las restricciones simplemente serían diferibles.

La penalización del rendimiento tiene que ver con las optimizaciones que la base de datos puede realizar dado el conocimiento de cómo se restringen los datos. Por ejemplo, el índice que se crea para respaldar una restricción única en Oracle no puede ser un índice único si la restricción es diferible, ya que se debe permitir el permiso temporal de duplicados. Sin embargo, si la restricción no se puede aplazar, el índice puede ser único.

Llego muy tarde a la fiesta, pero quería agregar que, a partir de diciembre de 2018, solo dos bases de datos que conozco (puede haber más) ofrecen algún nivel de implementación de esta característica estándar de SQL :

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 Aunque Oracle 12c acepta el NOT DEFERRABLE estado de restricción , en realidad lo ignora y lo hace funcionar comoDEFERRABLE INITIALLY IMMEDIATE .

Como ve, Oracle no implementa el primer tipo (NOT DEFERRABLE ), y es por eso que los desarrolladores que usan Oracle (el OP en este caso) pueden confundirse y considerar los dos primeros tipos equivalentes.

Curiosamente, Oracle y PostgreSQL tienen un tipo predeterminado diferente. Quizás tenga implicaciones en el rendimiento.

NO DEFERRABLE: no puede cambiar la comprobación de restricciones, Oracle la comprueba después de cada declaración (es decir, directamente después de insertar la declaración).

DEFERRABLE INICIALMENTE INMEDIATO: Oracle verifica la restricción después de cada declaración. PERO, puede cambiarlo después de cada transacción (es decir, después de confirmar):

set constraint pk_tab1 deferred;