Почему бы вам НЕ установить IGNORE_DUP_KEY в положение ON?

Question

IGNORE_DUP_KEY = ON в основном говорит SQL Server вставлять неповторяющиеся строки, но игнорирует любые дубликаты; поведение по умолчанию - выдавать ошибку и прерывать всю транзакцию, если в столбце есть дубликаты, которые их не допускают.

Я работал с тонной данных, у которых обычно есть хотя бы один дубликат, когда их не должно быть, поэтому мне нравится использовать ограничения UNIQUE, когда я знаю, что значение не должно иметь дублирования; однако, когда я пытаюсь выполнить массовую загрузку данных, последнее, что я хочу, это чтобы они выполнили 90%, а затем неожиданно натолкнулись на дубликат и выдали ошибку полностью (да, я знаю, что очевидное решение состоит в том, чтобы убедиться, что нет дубликатов) , но иногда мне просто передают электронную таблицу, заполненную данными, и говорят загрузить ее как можно скорее).

Итак, в чем причина того, что по умолчанию установлено значение OFF, и почему не будет , вы хотите, чтобы он был включен все время, чтобы любые записи без дублирования выполнялись успешно, пока вы не беспокоиться о любых дубликатах; Скорее всего, дубликаты там по ошибке в любом случае.

Это связано с производительностью или чем-то еще? Это кажется хорошей идеей, но должна быть какая-то причина, почему это не поведение по умолчанию.

В основном, есть ли веская причина , а не , использовать это, о чем я должен знать, или это должно быть для оценки в каждом конкретном случае?

Answer 1

Всякий раз, когда есть отклонение от «нормального» в базе данных, вы, вероятно, хотите знать об этом.

Вы сохранили ключ уникальным из-за некоторых ограничений, возникающих из-за потребностей бизнеса, которые продиктовали его. База данных просто поддерживает свою сторону сделки, говоря: «Эй, ты хотел, чтобы это было уникальным, но теперь ты говоришь что-то противоположное. Прими решение '

Если это умышленно, вы можете попросить базу данных закрыть, используя IGNORE_DUP_KEY:)

Answer 2

Скорее всего, дубликаты там по ошибке в любом случае.

Могу поспорить, что они есть! Это ошибки. Вы наверняка хотите знать о них! Тьюринг по IGNORE_DUP_KEY по умолчанию - это ...

1. прятаться от жуков ...
2. ... повреждением данных. (Конечно, база данных остается физически непротиворечивой, но данные все еще неверны с точки зрения бизнес-логики.)

Это ужасный выбор по любым меркам.

Включите его при особых обстоятельствах, а затем избавьтесь от него так быстро, как только сможете, чтобы случайно не скрыть ошибки.

Answer 3

Полагаю, это может быть связано с тем, что по умолчанию установлено предотвращение сбоя любых недопустимых транзакций. Учитывая все вышесказанное, я предпочел бы выбрать, когда игнорировать непредвиденные последствия, но, пожалуйста, дайте мне знать, если я не скажу иначе.

Пример: если я внесу свою зарплату, я бы хотел, чтобы кто-то заметил, если мой работодатель случайно выдал дубликаты чеков.

Answer 4

У меня отношение многие ко многим. У меня есть таблица товаров по категориям с уникальным индексом, в таблице нет других данных, кроме prodid и katid.

Поэтому я устанавливаю IGNORE_DUP_KEY для уникального индекса (prodid, katid).

Так что я могу смело сказать «добавить продукт (1,2,3) в категорию (a, b, c)», не проверяя, есть ли некоторые продукты уже в некоторых категориях; Я забочусь только о конечном результате.

Answer 5

Может использоваться как проверка работоспособности. Если вы знаете, что не должно быть никаких конфликтов, оставьте это, и он быстро потерпит неудачу на ошибках. OTOH для специальных консольных сессий, я понимаю вашу точку зрения.