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

Ответ 1

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

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

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

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

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

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

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

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

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

• Создание индекса UNIQUE

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

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

Ответ 2

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

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

Ответ 3

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

Ответ 4

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

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

Марк

Ответ 5

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

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

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

Ответ 6

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

Ответ 7

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

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

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

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

Ответ 8

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

Ответ 9

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

Ответ 10

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

Ответ 11

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

Ответ 12

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

Ответ 13

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

Ответ 14

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

Ответ 15

да пожалуйста очень полезно.

Ответ 16

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

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

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

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

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

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

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

Columns: Id, FirstName, LastName etc. 

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