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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Марк

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

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

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

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

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

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

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

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

Не согласен с предложенным ответом. Короткий ответ: НЕТ .

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

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

Небольшой пример: Таблица A: LogData

Columns:  DateAndTime, UserId, AttribA, AttribB, AttribC etc...

Первичный ключ не требуется.

Таблица B: Пользователь

Columns: Id, FirstName, LastName etc. 

Первичный ключ (Id) необходим для использования в качестве «внешнего ключа» для таблицы LogData.

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

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

Я нахожусь в роли поддержки приложения, созданного оффшорной командой разработчиков. Теперь у меня возникают всевозможные проблемы в приложении, потому что исходная схема базы данных не содержала ПЕРВИЧНЫЕ КЛЮЧИ в некоторых таблицах. Поэтому, пожалуйста, не позволяйте другим людям страдать из-за вашего плохого дизайна. Всегда полезно иметь первичные ключи на таблицах.

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

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

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