студия управления sql [дубликат]

Нет недостатков первичных ключей.

Чтобы добавить только некоторую информацию в ответы @MrWiggles и @Peter Parker, когда таблица не имеет первичного ключа, например, вы не сможете редактировать данных в некоторых приложениях (они в конечном итоге говорят, что sth не может редактировать / удалять данные без первичного ключа). Postgresql позволяет использовать несколько значений NULL в столбце UNIQUE, PRIMARY KEY не разрешает NULL.

UPDATE:

Насколько я знаю, невозможно реплицировать таблицы без первичных ключей в MSSQL, по крайней мере без проблем ( details ).

Мое понимание состоит в том, что первичный ключ и уникальный индекс с непустым ограничением одинаковы (*); и я полагаю, что один выбирает тот или иной, в зависимости от того, что спецификация явно заявляет или подразумевает (вопрос того, что вы хотите выразить и явно применять). Если для этого требуется уникальность и не-null, тогда сделайте его первичным ключом. Если это просто происходит, все части уникального индекса не являются нулевыми без каких-либо требований для этого, то просто сделайте его уникальным индексом.

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

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

Другие здесь упомянули репликацию БД, но я не знаю об этом.

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

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

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

Ограничение FOREIGN KEY не должно связываться только с ограничением PRIMARY KEY в другой таблице; его также можно определить для ссылки на столбцы ограничения UNIQUE в другой таблице

Для транзакционной репликации вам нужен первичный ключ. Из книг в Интернете:

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

Оба ответа предназначены для SQL Server 2005.

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

Есть некоторые недостатки CLUSTERED INDEXES против UNIQUE INDEXES.

Как уже было сказано, CLUSTERED INDEX физически заказывает данные в таблице.

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

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

Пока вы не разрешаете NULL для значения, они должны обрабатываться одинаково, но значение NULL обрабатывается по-разному в базах данных (AFAIK MS-SQL не допускает более одного (1) значения NULL, mySQL и Oracle разрешает это, если столбец UNIQUE). Поэтому вы должны определить этот столбец NOT NULL UNIQUE INDEX

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

Вы всегда должны добавить уникальный столбец с автоиндексированным идентификатором.

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

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

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

Для базы данных полезно идентифицировать логические записи, а не физические записи - то есть, что такое значение rowid () в выборе или просмотре нескольких таблиц.

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

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

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

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

Вы можете видеть это следующим образом:

Первичный ключ IS Unique

Уникальное значение не обязательно должно быть представлением элемента

Имея в виду?; Ну, первичный ключ используется для идентификации элемента, если у вас есть «Лицо», которое вы хотели бы иметь персональный идентификационный номер (SSN или такой), который является первичным для вашего лица.

С другой стороны , у человека может быть уникальное электронное письмо, но он не идентифицирует человека.

У меня всегда есть первичные ключи, даже в таблицах отношений (таблица таблицы / таблицы / таблицы), которые могут быть у меня их. Зачем? Ну, мне нравится следовать стандарту при кодировании, если у «Лица» есть идентификатор, у Автомобиля есть идентификатор, ну, тогда у Person -> Car также должен быть идентификатор!

В дополнение к тому, что говорили другие ответы, некоторые базы данных и системы могут требовать первичного присутствия. На ум приходит одна ситуация; при использовании репликации предприятия с Informix a PK должен присутствовать в таблице для участия в репликации.

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

Уникальные индексы не являются частью стандарта SQL. Конкретная реализация СУБД определит, каковы последствия объявления уникального индекса.

В Oracle объявление первичного ключа приведет к созданию уникального индекса от вашего имени, поэтому вопрос почти спорный. Я не могу рассказать вам о других продуктах СУБД.

Я предпочитаю объявление первичного ключа. Это приводит к запрету NULL в ключевом столбце (столбцах), а также запрещении дублирования. Я также одобряю объявление ограничений ССЫЛКИ для обеспечения целостности объектов. Во многих случаях объявление индекса на coulmn (s) внешнего ключа ускоряет объединение. Этот тип индекса вообще не должен быть уникальным.