¿Por qué NO deberías establecer IGNORE_DUP_KEY en ON?

IGNORE_DUP_KEY = ON básicamente le dice 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.¿Por qué NO deberías establecer IGNORE_DUP_KEY en ON?

He trabajado con una tonelada de datos que normalmente tiene al menos un duplicado cuando no debería haberlos, por lo que me gusta usar las 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).

Así que, ¿cuál es la razón para tener el valor por defecto será OFF, y por qué no habría que quieren que sea en todo el tiempo de modo que las entradas no duplicados tienen éxito mientras que usted no tiene que preocuparse cualquier duplicado; 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 una buena razón no para utilizar esto de lo que debería tener conocimiento, o debería estar disponible para evaluar caso por caso?

Fuente

2009-02-10 Wayne Molina

Siempre que haya una desviación de lo "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 esto es intencional puede pedir a la base de datos que se calle utilizando IGNORE_DUP_KEY :)

Fuente

2009-02-11 05:11:34 Learning

Un comentario, configurar el ignorar NO tiene consecuencias. Si tiene una columna de identidad, verá omisiones en la identidad de cada inserción que se haya ignorado debido a un duplicado. –

Tener esta opción en índices no agrupados da una penalización en el rendimiento [Mantener índices únicos con IGNORE_DUP_KEY] (https://blogs.msdn.microsoft.com/craigfr/2008/01/30/maintaining-unique-indexes-with -ignore_dup_key /) y puede dar como resultado un bloqueo de rango severo con lotes de inserción simultáneos [Rango de bloqueo (RS-U) debido a la opción de índice IGNORE_DUP_KEY] (http://aboutsqlserver.com/tag/locking/). Por lo tanto, cuando desee insertar muchas filas de una sola vez e ignorar los duplicados, aplíquelo solo en la clave agrupada. – eremmel

@eremmel ¡Acabas de guardar mi tocino, gracias por ese comentario! He estado golpeándome la cabeza contra la pared durante los últimos días tratando de descubrir por qué estaba obteniendo bloqueos de Range sin aislamiento serializable cuando recibí este pequeño cosquilleo en mi cerebro sobre ignore_dup_key causando problemas de rendimiento. La búsqueda rápida me llevó a esta publicación, ¡rock! Solo desearía que esta fuera una respuesta completa, por lo que era más obvio :) –

Se puede utilizar como 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.

Fuente

2009-02-10 19:07:52 BCS

Verdadero - Supongo que se trata de decidir si el escenario de "entrada duplicada" es excepcional o no y si debe generar un error, o simplemente ignorarlo. –

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 duplicados de cheques.

Fuente

2009-02-10 19:12:36 dkretz

Eso es cierto, también. Supongo que la mejor razón sería que se equivoca por precaución y genera un error a menos que usted le diga lo contrario. –

ocasiones son los duplicados está en ahí por error de todos modos.

Apuesto a que son! Ellos son errores. ¡Ciertamente quieres saber sobre ellos! Turing en IGNORE_DUP_KEYpor defecto es ...

insectos escondidos ...
... 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 comercial.)

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.

Fuente

2012-09-20 13:10:04 usr

Pero tanto la documentación como la pregunta afirman que no se pueden corromper los datos, porque incluso con IGNORE_DUP_KEY = ON no se permiten duplicados. –

@FrancoisBourgeois no estoy seguro de lo que dices. Los duplicados solo son posibles con un índice no único, por supuesto. Son errores de aplicación lógica, no errores en SQL Server. – usr

No está dañando los datos porque no inserta el valor duplicado, simplemente se salta sin generar una advertencia. – user3071296

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.

Fuente

2014-03-24 12:32:03

¿Por qué NO deberías establecer IGNORE_DUP_KEY en ON?

Respuesta

Cuestiones relacionadas