Должна ли таблица базы данных всегда иметь первичные ключи?

Question

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

Давайте возьмем SO тегирование. Вы можете увидеть тег в любой ревизии, скорее всего, он будет в таблице tag_rev с идентификатором postID и номером ревизии. Нужен ли мне ПК для этого?

Кроме того, поскольку он находится в таблице оборотов и в настоящее время не использует теги, следует использовать двоичный объект tagID вместо нескольких записей нескольких пар тегов post_id?

Answer 1

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

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

Answer 2

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

Я не знаю, как выглядит схема базы данных Stack Overflow (и из некоторых вещей, которые я прочитал в блоге Джеффа, я не хочу), но в описанной вами ситуации это вполне возможно. является первичным ключом идентификатора записи, номера редакции и значения тега; конечно, это был бы самый короткий (и единственный) доступный суперключ.

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

Answer 3

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

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

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

Answer 4

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

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

Подробнее о тегах и ключах см. В следующем вопросе:

Id для тегов в системах тегов

Answer 5

Из раздела Справочного руководства MySQL 5.5 13.1.17 :

Если у вас нет PRIMARY KEY и приложение запрашивает PRIMARY KEY в ваших таблицах, MySQL возвращает первый индекс UNIQUE, в котором в качестве PRIMARY KEY нет столбцов NULL.

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

Answer 6

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

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

Answer 7

Если это таблица соединений, то я бы не сказал, что вам нужен первичный ключ. Предположим, например, что у вас есть таблицы PERSONS, SICKPEOPLE и ILLNESSES. В таблице ILLNESSES есть такие вещи, как грипп, простуда и т. Д., Каждый из которых имеет первичный ключ. У людей есть обычные вещи о людях, у каждого также есть первичный ключ. В таблице SICKPEOPLE есть только больные люди, и она имеет два столбца, PERSONID и ILLNESSID, внешние ключи обратно в соответствующие таблицы и не имеет первичного ключа. Таблицы PERSONS и ILLNESSES содержат сущности, а сущности получают первичные ключи. Записи в таблице SICKPEOPLE не являются сущностями и не получают первичные ключи.

Answer 8

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

Примечание: это не отвечает тону "Великой объединенной теории" вашего вопроса, но я просто говорю, что на практике иногда вы ДОЛЖНЫ создавать первичный ключ для каждой таблицы.

Answer 9

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

Answer 10

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