Можно ли легко обнаружить или предсказать нарушение первичного ключа в SQL?

Question

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

SELECT ProductCode FROM tblProducts WHERE ProductCode = '12345'

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

Интересно, если это проблема типа P = NP или я переосмыслил проблему?
Моя база данных - MS SQL Server 2000, если это помогает.

Answer 1

Я бы порекомендовал просто допустить сбой вставки SQL и позволить SQL Server устранить ошибку нарушения первичного ключа и устранить ее. SQL Server поддерживает индекс, и они делают это в течение многих лет. Я уверен, что их реализация будет во много раз лучше, чем у большинства разработчиков. Если вы пытаетесь запрограммировать это, вам нужно будет прочитать все ключи и сохранить их где-нибудь в индексе. SQL Server уже делает это. Итак, у вас есть двойная проверка и удвоение количества необходимого пространства.

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

В противном случае позвольте SQL Server делать то, что он хорош, а вы делаете все остальное:)

Answer 2

Просто разрешите SQL тестировать перед вставкой

IF NOT EXISTS (SELECT * FROM tblProducts WHERE tblProducts = '12345')
    INSERT tblProducts (tblProducts, columnlist, ...)
    VALUES ('12345', valuelist, ...)

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

Answer 3

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

Answer 4

Возможно, проблема в дизайне вашего веб-приложения? Вы уверены, что данные в вашей базе данных видоизменяются только через HTTP POST? Затем убедитесь, что срок действия этих ответов на странице равен нулю или сейчас (я не могу вспомнить, основан ли он на дате или миллисекундах). Таким образом, пользователи, получившие ответный удар, увидят сообщение «Вы хотите отправить данные формы» или получите ссылку «Страница устарела» в браузере.

Далее любая страница, которая принимает ввод пользователя, должна быть отказоустойчивой. Кажется, ваш первичный ключ введен вашими пользователями. Однако, даже если это не так, разумно иметь введенный уникальный ключ, а не вычисленные данные.

Какова ваша общая стратегия для решения этой ситуации? (Это не p = np) Эта проблема сталкивается со многими приложениями жанра базы данных. Похоже, что другие авторы предложили некоторые решения этой проблемы.

Удачи

Answer 5

Полагаю, это зависит от того, как часто это может происходить.

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

Если бы это могло происходить довольно часто, я бы сначала проверил, в порядке ли мой новый элемент, и только в том случае, если это так на самом деле для вставки. С другой стороны, если это происходит довольно часто, значит, что-то не так с логикой вашего приложения, я бы сказал - у вас должен быть надежный способ создания и назначения первичных ключей, которые являются уникальными (и, таким образом, никогда не вызывать конфликты вставки), например используя столбец INT IDENTITY или каким-либо другим способом.

Марк