Должна ли каждая таблица иметь первичный ключ?

Question

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

Должна ли каждая таблица иметь первичный ключ?

Answer 1

Краткий ответ: да .

Длинный ответ:

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

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

Обратите внимание, что первичный ключ может быть составным.

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

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

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

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

• Создание индекса УНИКАЛЬНО

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

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

Answer 2

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

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

Answer 3

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

Если у него нет первичного ключа, это не таблица!

Марк

Answer 4

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

Answer 5

Вам когда-нибудь понадобится присоединить этот стол к другим столам? Вам нужен способ уникальной идентификации записи? Если ответ «да», вам нужен первичный ключ. Предположим, ваши данные похожи на таблицу клиентов, в которой есть имена людей, которые являются клиентами. Там может не быть естественного ключа, потому что вам нужны адреса, электронные письма, номера телефонов и т. Д., Чтобы определить, отличается ли эта Салли Смит от той, что Салли Смит, и вы будете хранить эту информацию в связанных таблицах, так как у человека может быть несколько телефонов, адреса Предположим, Салли Смит выходит замуж за Джона Джонса и становится Салли Джонс. Если у вас нет искусственного ключа на столе, когда вы обновляете имя, вы просто изменили 7 Салли Смитс на Салли Джонс, хотя только одна из них вышла замуж и сменила имя. И, конечно, в этом случае без искусственного ключа, как узнать, какая Салли Смит живет в Чикаго, а какая в Лос-Анджелесе?

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

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

Answer 6

Просто добавьте его, вы будете сожалеть позже, когда вы этого не сделали (выбор, удаление. Ссылки и т. Д.)

Answer 7

Рекомендуется иметь ПК на каждом столе, но это НЕ ДОЛЖНО. Скорее всего, вам понадобится уникальный индекс и / или кластерный индекс (который является PK или нет) в зависимости от ваших потребностей.

Ознакомьтесь с разделами Первичные ключи и Кластерные индексы в электронной документации (для SQL Server)

" Ограничения PRIMARY KEY идентифицируют столбец или набор столбцов, которые имеют значения, однозначно идентифицирующие строку в таблице. Никакие две строки в таблице не могут иметь одинаковое значение первичного ключа. Вы не можете ввести NULL для любого столбца в первичном ключе. Рекомендуется использовать небольшой целочисленный столбец в качестве первичного ключа. Каждая таблица должна иметь первичный ключ. Столбец или комбинация столбцов, которые квалифицируются как значение первичного ключа, упоминается как ключ-кандидат. «

Но тогда проверьте это также: http://www.aisintl.com/case/primary_and_foreign_key.html

Answer 8

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

Answer 9

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

Answer 10

У меня всегда есть первичный ключ, даже если вначале у меня еще не было цели для него. Было несколько раз, когда мне в конце концов понадобился ПК в таблице, в которой его нет, и всегда сложнее вставить его позже. Я думаю, что есть преимущество в том, чтобы всегда включать один.