Как лучше всего использовать первичные ключи в таблицах? - PullRequest
Новая
       102

Как лучше всего использовать первичные ключи в таблицах?

235 голосов
/ 03 декабря 2008

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

  1. Столбец целочисленного идентификатора, который автоматически увеличивается.
  2. Уникальный идентификатор (GUID)
  3. столбец с короткими символами (x) или целым числом (или другим относительно небольшим числовым типом), который может служить столбцом идентификатора строки

Номер 3 будет использоваться для довольно небольшого поиска, в основном для чтения таблиц, которые могут иметь уникальный строковый код статической длины, или числового значения, такого как год или другое число.

По большей части все остальные таблицы будут иметь автоинкрементное целое число или первичный ключ с уникальным идентификатором.

Вопрос: -)

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

  • DateTime / символ
  • Дата и время / VARCHAR
  • символ / NVARCHAR / NVARCHAR

Есть ли веские доводы для этого? Я бы всегда определял столбец идентификаторов или уникальных идентификаторов для этих случаев.

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

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

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

Ответы [ 21 ]

0 голосов
/ 31 декабря 2008

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

  • идентификатор строки (GUID)
  • Creator (строка; по умолчанию используется имя текущего пользователя (SUSER_SNAME() в T-SQL))
  • Создано (DateTime)
  • Отметка

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

Между тем, фактический PK является, если возможно, естественным ключом. Мои внутренние правила примерно такие:

  • Люди - используйте суррогатный ключ, например, INT. Если он внутренний, то GUID пользователя Active Directory является приемлемым выбором
  • Таблицы поиска (например, StatusCodes) - используйте короткий код CHAR; его легче запомнить, чем INT, и во многих случаях бумажные формы и пользователи также будут использовать его для краткости (например, Status = "E" для "Expired", "A" для "Approved", "NADIS" для "No Asbstos Detected" В образце ")
  • Связывание таблиц - комбинация FK (например, EventId, AttendeeId)

Таким образом, в идеале вы получите естественный, читаемый человеком и запоминающийся ПК, а также ORM-ориентированный GUID «один идентификатор на таблицу».

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

Страница:
...