УНИКАЛЬНЫЕ Ограничения в SQL (SQL Server)

Question

Зачем нужны уникальные ограничения в базе данных?

Можете ли вы привести примеры?

Первичный ключ по умолчанию является УНИКАЛЬНЫМ ... Понятно, поскольку они упоминаются в других таблицах как Внешние ключи ... требуется связь для их соединения для платформы rdbms ...

но почему бы называть другие столбцы УНИКАЛЬНЫМИ, какая польза от этого?)

Answer 1

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

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

Answer 2

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

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

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

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

Вторая статья в серии Селко об ограничениях конкретно касается уникальных ограничений .

Answer 3

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

Answer 4

имя пользователя уникально, но не PK. Идентификатор пользователя - PK.

Answer 5

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

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

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

Answer 6

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

Вы можете использовать УНИКАЛЬНЫЕ ограничения, чтобы убедиться, что в конкретных столбцах не вводятся повторяющиеся значения, которые не участвуют в первичном ключе. Хотя и ограничение UNIQUE, и ограничение PRIMARY KEY обеспечивают уникальность, используйте ограничение UNIQUE вместо ограничения PRIMARY KEY, если вы хотите применить уникальность столбца или комбинации столбцов, которые не являются первичным ключом. 1007 * НТН

Answer 7

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

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