Идентификационные поля в таблицах SQL: правило или закон?

Question

Просто быстрый вопрос проектирования базы данных: ВСЕГДА используете поле идентификатора в КАЖДОЙ таблице или только в большинстве из них? Очевидно, что большинство ваших таблиц выиграют, но есть ли таблицы, в которых вы можете не использовать поле идентификатора?

Например, я хочу добавить возможность добавлять теги к объектам в другой таблице (foo). Итак, у меня есть таблица FooTag с полем varchar для хранения тега и полем fooID для ссылки на строку в foo. Нужно ли создавать кластерный индекс вокруг произвольного поля идентификатора? Разве не было бы более эффективно использовать fooID и мое текстовое поле в качестве кластеризованного индекса, так как я почти всегда буду искать по fooID? Кроме того, использование моего текста в кластерном индексе сохранит сортировку данных, упрощая сортировку, когда мне придется запрашивать данные. Недостатком является то, что вставки будут занимать больше времени, но разве это не будет компенсировано усилением во время выбора, что будет происходить гораздо чаще?

Что вы думаете о полях идентификаторов? Гибкое правило или нерушимый закон?

edit: Мне известно, что приведенный пример не нормализован. Если пометка должна быть основной частью проекта, с пометкой нескольких таблиц и других «дополнений», решение с двумя таблицами будет четким ответом. Однако в этом простейшем случае целесообразно ли нормализация? Это сэкономит место, но потребует дополнительного объединения при выполнении запросов

Answer 1

Как и в большинстве программ: правило, а не закон .

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

Answer 2

Если вы создаете таблицы, которые соединяют две или более других таблиц и единственные поля, которые вам нужны, это двойные PK / FK, тогда я не знаю, зачем вам нужен столбец ID там же.

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

Answer 3

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

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

Answer 4

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

Answer 5

Как правило, разработчики любят иметь поле идентификатора во всех таблицах, кроме «связывания» таблиц, потому что это значительно упрощает разработку, и я не исключение. Администраторы баз данных, с другой стороны, не видят проблем с созданием естественных первичных ключей, состоящих из 3 или 4 столбцов. Попытка получить хороший дизайн базы данных может оказаться трудной задачей.

Answer 6

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

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

Что касается индексов на этом проекте, то это будет продиктовано шаблонами использования.

Answer 7

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