суррогатные ключи против составных ключей

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

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

Заранее спасибо.


sql database sqlite database-schema
person jobobo    schedule 24.10.2011    source источник
comment
3 столбца для уникального ключа -- Те же 3 столбца? Это звучит как плохой дизайн схемы. Объедините таблицы вместе. NULLs представляют меньшую проблему, чем грязные LEFT JOINs.   -  person Rick James    schedule 30.12.2018

Ответы (1)


arrow_upward
4
arrow_downward

Каждая техника имеет преимущества и недостатки.

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

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

Два дополнительных преимущества суррогатного ключа:

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

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

person Larry Lustig    schedule 24.10.2011
comment
Зачем добавлять еще одну таблицу при использовании PK с автоматическим увеличением и суррогатного ключа в качестве ключа-кандидата? Я отказался от /не/ наличия одного PK - хотя SQLite всегда предоставляет ROWID, также известный как int PK, - но все же обнаружил, что информация все еще может быть закодирована в модели с соответствующими ограничениями, в стоимость другого [кандидатного/покрывающего] индекса, который может быть дешевле с точки зрения уменьшения фрагментации при вставке. Если индекс-кандидат денормализует таблицу, то он никогда не был допустимым кандидатом для [суррогатного] ПК с самого начала... - person ; 24.10.2011
comment
Спецификация с продуктом, подсборкой, компонентом. В Sub-Assembly (ProductID, AssemblyName) уникален. Если вы используете это как PK и FK в компоненте, вы можете найти использование компонента продуктом, используя только компонент. Если вместо этого вы используете суррогатный целочисленный первичный ключ, вы должны ПРИСОЕДИНИТЬСЯ к подсборке (или использовать метод подзапроса), чтобы получить эту информацию. - person Larry Lustig; 24.10.2011
comment
Спасибо за лаконичный ответ. Суррогат сейчас больше нравится, потому что большинство моих запросов, вероятно, не будут основаны на ключе (а скорее на атрибутах, например, счете). Хотя построение базы данных и редактирование кажутся более трудоемкими, а запросы могут занимать больше времени. - person jobobo; 24.10.2011