Первичный ключ по сравнению с ограничением на уникальность данных?

Я утверждаю, что Вам, возможно, понадобятся оба. Первичные ключи по своей природе должны быть уникальными и не nullable. Они часто - суррогатные ключи, поскольку целые числа создают более быстрые соединения, чем символьные поля и особенно, чем несколько полевых соединений символа. Однако, поскольку они часто автоматически генерируются, они не гарантируют уникальности записи данных, исключая сам идентификатор. Если Ваша таблица имеет естественный ключ, который должен быть уникальным, у Вас должен быть уникальный индекс на ней для предотвращения ввода данных дубликатов. Это - требование целостности основных данных.

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

Если Вы запланируете использование LINQ к SQL, Ваши таблицы потребуют Первичных ключей, если Вы запланируете выполнение обновлений, и они потребуют timestamp столбец, если Вы запланируете работу в разъединенной среде (такой как передача объекта через сервисное приложение WCF).

, Если Вам нравится.NET, PK и FK являются Вашими друзьями.

Я записал много на этом предмете: если Вы читаете, что-либо мое ясны, что я, вероятно, отсылал конкретно к Струе иначе Доступ MS.

В Струе, таблицы физически заказаны на PRIMARY KEY с помощью несохраняемого кластерного индекса (кластеризируется на компактном). Если таблица не будет иметь никакого PK, но действительно будет иметь ключи-кандидаты определенными с помощью ограничений UNIQUE на столбцы NOT NULL тогда, то механизм выберет один для кластерного индекса (если таблица не будет иметь никакого кластерного индекса тогда, это называют "кучей", возможно не таблица вообще!), Как механизм выбирает ключ-кандидат? Это может выбрать тот, который включает nullable столбцы? Я действительно не знаю. Дело в том, что в Струе единственный явный способ определить кластерный индекс к механизму состоит в том, чтобы использовать PRIMARY KEY. Существует, конечно, другое использование для PK в Струе, например, это будет использоваться в качестве ключа, если Вы будете опущены от объявления FOREIGN KEY в DDL SQL, но снова почему бы не явный.

проблема со Струей состоит в том, что большинство людей, которые составляют таблицы, не знает или беззаботное по отношению к кластерным индексам. На самом деле большинство пользователей (я держу пари), помещает автоинкрементный столбец Autonumber на каждую таблицу и определяют PRIMARY KEY только на этом столбце при отказе поместить любые ограничения на уникальность данных на естественные ключевые и ключи-кандидаты (может ли столбец автоприращения на самом деле рассматриваться как ключ, не представляя его конечным пользователям, другое обсуждение сам по себе). Я не буду вдаваться в подробности о кластерных индексах здесь, но достаточен, чтобы сказать, что IMO единственный столбец автоприращения редко к идеальному выбору.

Независимо от того, что Вы механизм SQL, выбор PRIMARY KEY произволен и конкретный механизм. Обычно механизм будет применять особое значение к PK, поэтому необходимо узнать то, что это, и используйте его в ваших интересах. Я поощряю людей использовать ограничения UNIQUE NOT NULL в надежде, которую они уделят большему вниманию всем ключам-кандидатам, особенно когда они приняли решение использовать столбцы 'автоматического номера', которые (не должны) иметь никакого значения в модели данных. Но я быть бы народ выбирать тот хорошо рассмотренный ключевой и используемый PRIMARY KEY вместо того, чтобы поместить его на столбец автоприращения из привычки.

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

BTW Chris OC делает правильное замечание здесь о временных таблицах, которые требуют упорядоченных первичных ключей (нижний регистр), который не может быть реализован через простые ограничения PRIMARY KEY (ключевые слова SQL в верхнем регистре).

Я обычно использую и PK и УНИКАЛЬНЫЙ КЛЮЧ. Поскольку, даже если Вы не обозначаете PK в своей схеме, каждый всегда сгенерирован для Вас внутренне. Это верно и для SQL Server 2005 и для MySQL 5.

, Но я не использую столбец PK в своем SQLs. Это - в целях управления как DELETEing некоторые ошибочные строки, узнавая разрывы между значениями PK, если это установлено на АВТОМАТИЧЕСКИЙ ИНКРЕМЕНТ. И, имеет смысл иметь PK как числа, не ряд массивов columns или массивов символов.

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

, я предполагаю, что единственная точка здесь является тем же старым обсуждением, "естественным по сравнению с суррогатными ключами", потому что уникальные индексы и pkВґs являются тем же самым.

перевод:

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

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

ЛИЧНО, я использую или GUID или автоувеличивающий BIGINTS (Идентификационные данные Вставляют для SQL-СЕРВЕРА) для уникальных ключей, используемых для перекрестных ссылок среди моих таблиц. Тогда я буду использовать другие данные, чтобы позволить пользователю выбирать определенные записи.

, Например, у меня будет список сотрудников, и присоединять GUID к каждой записи, которую я использую негласно, но когда пользователь выбирает сотрудника, они выбирают их базирующийся прочь следующих полей: LastName + FirstName + EmployeeNumber.

Моим первичным ключом в этом сценарии является LastName + FirstName + EmployeeNumber, в то время как уникальный ключ является связанным GUID.

Мы должны сделать различие здесь между логическими конструкциями и физическими конструкциями, и так же между теорией и практикой.

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

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

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

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

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

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

2 - уникальный индекс будет автоматически помещен в первичный ключ, таким образом, Вы не должны будете создавать тот.

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

4 - много сред разработки фронтэнда требуют первичного ключа, чтобы обновить таблицу или сделать удаления.

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

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

Вы должны всегда , имеют первичный ключ.

Однако я подозреваю, что Ваш вопрос просто сформулирован вводящий в заблуждение бит, и Вы на самом деле означаете спрашивать, должен ли первичный ключ всегда быть автоматически сгенерированным числом (также известный как суррогатный ключ), или некоторое уникальное поле, которое является фактическими значимыми данными (также известный как естественный ключ), как SSN для людей, ISBN для книг и так далее.

Этим вопросом является возраст старая религиозная война в поле DB.

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

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

ограничение на уникальность данных А использовалось бы, когда Вы хотите гарантировать уникальность в столбце В ДОПОЛНЕНИЕ К первичному ключу.

правило всегда имеет PK, хороший.

http://msdn.microsoft.com/en-us/library/ms191166.aspx

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

я ожидаю, что люди, которые приводят доводы против них, не видят оснований для обработки одного ключа по-другому, чем другой. Это - то, где я стою.

[Редактирование], По-видимому, я не могу прокомментировать даже свой собственный ответ без 50 точек.

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

Первичный ключ действительно просто ключ-кандидат , который не допускает ПУСТОЙ УКАЗАТЕЛЬ. По сути, в терминах SQL - это не отличается, чем какой-либо другой уникальный ключ.

Однако для нашего нетеоретического RDBMS, у Вас должен быть Первичный ключ - я никогда не слышал, что он спорил иначе. Если тот Первичный ключ суррогатный ключ , то Вы должны также , имеют ограничения на уникальность данных на естественный ключ (ключи) .

важный бит, чтобы уйти с - то, что у Вас должны быть ограничения на уникальность данных на весь кандидат (или естественный или суррогатный) ключи. Необходимо тогда выбрать тот, который является самым легким к ссылке в Внешний ключ , чтобы быть Primary Key*.

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

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

• Редактирование: было указано, что термин Oracle "кластеризованной таблицы" и "кластерного индекса" отличается, чем SQL-сервер. Эквивалент того, о чем я говорю в Oracle-ese, Индекс Заказанная Таблица , и это рекомендуется для таблиц OLTP - который, я думаю, был бы основной фокус ТАК вопросов. Я принимаю, ответственны ли Вы за большое хранилище данных OLAP, у Вас должны уже быть свои собственные мнения о проектировании баз данных и оптимизации.