Столбец идентификации как первичный ключ - PullRequest
Новая
       36

Столбец идентификации как первичный ключ

2 голосов
/ 03 декабря 2009

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

Спасибо Найн

Ответы [ 3 ]

4 голосов
/ 03 декабря 2009

Да, использование INT (или BIGINT) IDENTITY - очень хорошая практика для SQL Server.

SQL Server использует первичный ключ в качестве ключа кластеризации по умолчанию, и ключ кластеризации всегда должен иметь следующие свойства:

  • узкая
  • статические
  • уникальный
  • постоянно увеличивающийся

INT IDENTITY идеально отвечает всем требованиям!

Дополнительную справочную информацию и, в особенности, некоторую информацию о том, почему GUID в качестве основного (и, следовательно, ключа кластеризации) является плохой идеей, см. В превосходных публикациях Кимберли Триппа:

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

Марк

3 голосов
/ 03 декабря 2009

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

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

0 голосов
/ 03 декабря 2009

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

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

...