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

Question

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

Answer 1

Когда вы, вероятно, БЫЛИ:

В базе данных OLTP у вас почти всегда (в моем случае всегда) есть какой-то первичный ключ. Иногда Guid, иногда поля автонумерации / идентификации, иногда устанавливаемые приложением или заказчиком. Иногда даже комбинация из более чем одного поля. Это потому, что вы, как правило, хотите однозначно идентифицировать любую строку в таблице.

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

Когда вы, вероятно, НЕ ХОТИТЕ:

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

Answer 2

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

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

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

http://www.dbdebunk.com/page/page/627052.htm

http://www.dbdebunk.com/page/page/638922.htm

http://dl.acm.org/citation.cfm?id=77708

http://www.amazon.com/Practical-Issues-Database-Management-Practitioner/dp/0201485559

Answer 3

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

Но, НЕ в каждой таблице должен быть один столбец идентификатора автоматического номера.Я чувствовал необходимость разъяснить это, потому что по какой-то причине многие люди склонны добавлять дополнительные идентификаторы во все таблицы, даже если уже существует достаточно хороший кандидат.Например, таблица «многие ко многим», представляющая Users <-> Groups, должна использовать {user_id, group_id}.

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

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

Answer 4

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

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

Answer 5

Как правило, да - я бы сделал исключения для таблиц, которые представляют собой просто свернутые версии «реальных» данных, хранящихся для целей отчетности (т. Е. Сводные таблицы, созданные для целей отчетности / производительности), но обычно у меня всегда есть первичный ключ - и в моих приложениях это почти всегда целочисленное значение с автоинкрементом, которое практически не занимает дополнительного места относительно размера строки.

Answer 6

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

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

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

Answer 7

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