sql server - pad_index - ¿Por qué NO deberías establecer IGNORE_DUP_KEY en ON?

set ignore_dup_key sql server

Question

IGNORE_DUP_KEY = ON le dice básicamente a SQL Server que inserte filas que no sean duplicadas, pero ignora silenciosamente cualquier duplicado; el comportamiento predeterminado es generar un error y cancelar toda la transacción cuando hay duplicados en una columna que no los permite.

He trabajado con una tonelada de datos que normalmente tiene al menos un duplicado cuando no debería haberlos, por lo que me gusta hacer uso de restricciones UNIQUE cuando sé que un valor no debería tener dups; sin embargo, cuando trato de cargar datos a granel, lo último que quiero es que se complete al 90% y de repente se ejecute un duplicado y se corrompe todo (sí, sé que la solución obvia es asegurarse de que no haya duplicados) , pero a veces me acaban de entregar una hoja de cálculo llena de datos y me dicen que la cargue lo antes posible).

Entonces, ¿cuál es el motivo por el que el valor predeterminado está OFF Y ¿por qué no desea que esté activo todo el tiempo para que las entradas que no sean duplas tengan éxito mientras no tenga que preocuparse por los duplicados? lo más probable es que los duplicados estén ahí por error de todos modos.

¿Está relacionado con el rendimiento u otra cosa? Esto parece una gran idea, pero tiene que haber alguna razón por la cual no sea el comportamiento predeterminado.

Principalmente, ¿hay alguna buena razón para no usar esto de lo que debería estar al tanto, o debería evaluarse caso por caso?

Answer 1

Se puede usar como un control de cordura. Si sabes que no debería haber conflictos, déjalo y fallará rápidamente en los errores. OTOH para sesiones de consola ad-hoc, veo tu punto.

Answer 2

Supongo que podría ser porque los valores predeterminados están configurados para evitar que las transacciones no válidas fallen en silencio. Todo considerado, preferiría elegir cuándo ignorar las consecuencias involuntarias, pero por favor avíseme a menos que diga lo contrario.

Ejemplo: si estoy depositando mi cheque de pago, me gustaría que alguien lo notara si mi empleador emitió accidentalmente números de cheques duplicados.

Answer 3

Cada vez que hay una desviación de la "normal" en la base de datos, es probable que desee saber al respecto.

Mantuvo la clave única debido a alguna restricción derivada de la necesidad comercial que la dictaba. La base de datos simplemente está manteniendo su lado del trato diciendo que ''oye querías que esto fuera único pero ahora estás diciendo algo en contra. Decídete''

Si eso es intencional, puede pedirle a la base de datos que se calle utilizando IGNORE_DUP_KEY :)

Answer 4

Estoy teniendo una relación de muchos a muchos. Tengo una tabla de producto a categoría con un índice único, no hay más información que la de prodid y katid en la tabla.

Así que estoy configurando IGNORE_DUP_KEY en el índice único (prodid, katid).

Así que puedo decir con seguridad "agregar producto (1,2,3) a la categoría (a, b, c)" sin tener que verificar si algunos productos ya están en algunas categorías; Solo me importa el resultado final.

Answer 5

lo más probable es que los duplicados estén ahí por error de todos modos.

¡Apuesto a que lo son! Ellos son errores. ¡Ciertamente quieres saber sobre ellos! Turing en IGNORE_DUP_KEY de forma predeterminada es ...

1. escondiendo errores ...
2. ... corrompiendo datos. (Por supuesto, la base de datos se mantiene físicamente consistente, pero los datos siguen siendo incorrectos desde el punto de vista de la lógica de negocios).

Esta es una elección terrible de cualquier estándar.

Actívela en circunstancias especiales y luego deshágase de ella lo más rápido que pueda para no ocultar errores por accidente.