NO DEFERRABLE versus DEFERRABLE INICIALMENTE INMEDIATO

Question

He leído esto sobre la palabra clave SQL DEFERRABLE en Sistemas de bases de datos - El libro completo.

The latter [NOT DEFERRABLE] is default, and means that every time a database modification statement is executed, the constraint is checked immediately afterwards, if the modification could violate the foreign-key constraint.

However, if we declare a constraint to be DEFERRABLE, then we have the option of having it wait until a transaction is complete before checking the constraint.

We follow the keyword DEFERRABLE by either INITIALLY DEFERRED or INITIALLY IMMEDIATE. In the former case, checking will be deferred to just before each transaction commits. In the latter case, the check will be made immediately after each statement.

¿Cómo es diferente de NOT DEFERRABLEDEFERRABLE INITIALLY IMMEDIATE? En ambos casos, parece que cualquier restricción se verifica después de cada declaración individual.

Answer 1

Con DEFERRABLE INITIALLY IMMEDIATE puede aplazar las restricciones a pedido 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 aplazar la verificación hasta el momento de la confirmación.

La sintaxis de cómo diferir las restricciones es diferente para los diversos DBMS.

Con NOT DEFERRABLE nunca podrá postergar la verificación hasta el momento de la confirmación.

Answer 2

Aparte de lo obvio de poder posponer, la diferencia es en realidad el rendimiento. Si no hubiera una penalización por desempeño, entonces no habría necesidad de tener una opción para elegir diferible o no, todas las restricciones serían simplemente 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 deben permitir temporalmente los duplicados. Sin embargo, si la restricción no es diferible, entonces el índice puede ser único.

Answer 3

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

DEFERRABLE INMEDIATAMENTE INMEDIATO: Oracle verifica la restricción después de cada instrucción. Pero, se puede cambiar a después de cada transacción (es decir, después de comprometerse):

set constraint pk_tab1 deferred; 

Answer 4

Aparte de las otras respuestas (correctas), es preciso señalar que:

• con NO DEFERRABLE cada fila se comprueba en el momento de inserción/actualización

• con DEFERRABLE (actualmente INMEDIATA) todas las filas son c hecked al final de la inserción/actualización

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

Así no es correcta decir que una restricción DEFERRABLE actúa como una NO DEF ERRABLE cuando está configurada como INMEDIATA.

---

Vamos a explicar en detalle 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 da salida correcta:

Pero si quitamos la instrucción INICIALMENTE INMEDIATA DEFERRABLE,

ERROR: duplicate key value violates unique constraint "example_row_col_key" DETAIL: Key ("row", col)=(2, 2) already exists. ********** Error **********

ERROR: duplicate key value violates unique constraint "example_row_col_key" SQL state: 23505 Detail: Key ("row", col)=(2, 2) already exists.

---

ADENDA(12 de octubre, 2017)

Este comportamiento es, en efecto documentado here, sección "Compatibilidad":

Also, PostgreSQL checks non-deferrable uniqueness constraints immediately, not at end of statement as the standard would suggest.