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

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

7 ответов


когда вы, вероятно:

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

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

когда вы, вероятно, не:

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


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

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


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

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

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

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


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

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

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

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


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


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

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

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


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