Составной ключ или первичный ключ BigInt — что меньшее зло?

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

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

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

ОБНОВЛЕНИЕ:

Я хочу уточнить, что составной ключ, который я рассматриваю, не является естественным составным ключом. Он содержит только идентификатор и дискриминатор подтипа. Мне интересно использовать его как способ избежать ограничений размера первичного ключа int. Мои основные опасения:

1) Есть ли проблемы с производительностью при использовании первичных ключей Int64? Особенно в таблице для наследования типов, где это необходимо только для родительской таблицы, но также должно использоваться в дочерних таблицах.

2) Предоставляет ли использование составного ключа (неестественного) для достижения большего диапазона, чем первичный ключ int, какие-либо преимущества в производительности по сравнению с использованием ключа Int64 для выполнения той же задачи?


.net entity-framework composite-primary-key bigint table-per-type
person lintmouse    schedule 05.09.2013    source источник
comment
Какого ответа вы ожидаете, кроме мнений?   -  person John Dvorak    schedule 05.09.2013
comment
Я слышу вас, но мнения могут помочь мне взвесить варианты.   -  person lintmouse    schedule 05.09.2013
comment
Почему бы вам не заглушить базовое приложение, которое демонстрирует, как вы собираетесь использовать базу данных и профилировать каждый проект? Мое первоначальное мнение - не беспокоиться об этом и использовать то, что имеет смысл, в настоящее время это кажется bigint решением. Базы данных могут довольно эффективно обрабатывать целочисленные значения, и я был бы удивлен, если бы это стало вашей первой серьезной проблемой.   -  person Adam Houldsworth    schedule 05.09.2013
comment
Я предпочитаю иметь единственный ключ, даже если он является суррогатным и настоящий естественный ключ существует. Это просто делает объединение этой таблицы намного проще, если вам нужно объединить только один столбец - вместо того, чтобы ваши 2, 3, 5 или 10 составных ключевых столбцов колебались по всей вашей модели - только так можно присоединиться....   -  person marc_s    schedule 05.09.2013
comment
Нет необходимости идти на компромисс. Вам не нужно выбирать только один. Таблицы могут иметь несколько ключей. Используйте как единый суррогатный ключ для соединений и FK, так и составной естественный ключ, чтобы обеспечить согласованность данных.   -  person Charles Bretana    schedule 05.09.2013

Ответы (1)


arrow_upward
1
arrow_downward

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

BigintId  firstName LastName   Phone        Gender   Birthdate
  1         Bob      Smith    111 234-5678    M     1 jan 1978
  2         Bob      Smith    111 234-5678    M     1 jan 1978
  3         Bob      Smith    111 234-5678    M     1 jan 1978
  4         Bob      Smith    111 234-5678    M     1 jan 1978

Это действительно разные сущности только потому, что у них разные идентификаторы? Только если мы вслепую переопределим другой, чтобы просто означать, что у него другой ключ...

person Charles Bretana    schedule 05.09.2013