Ограничения UNIQUE в SQL (SQL Server)

Есть несколько различий между PK и UQ . PK не может иметь значений NULL, тогда как UQ может иметь 1 значение NULL (Oracle допускает несколько значений NULL). У вас может быть только 1 PK на таблицу, но у вас может быть несколько UQ для таблицы PK по умолчанию кластеризован (но не обязательно)

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

Уникальное ограничение МОЖЕТ быть полезным, например, для столбца адреса электронной почты, которое требует, чтобы никакие две строки не имели одинаковых адресов электронной почты - хотя это не будет PK, и обычно его можно изменить.

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

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

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

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

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

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

В большинстве случаев при проектировании базы данных мы сохраняем наши первичные ключи как поля идентификации. Несмотря на то, что имеет смысл сделать его полем идентификации, это может не решить проблему достижения уникальности. Чтобы убедиться, что строка уникальна, мы накладываем уникальное ограничение на столбец (как Андрей указал UserNane). Вот что говорит MSDN:

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

HTH

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

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

emailID может быть уникальным. Разница

между uniqueID и Первичный ключ является уникальным, поддерживает единственный нуль во всем столбце, но PK не будет.