Не могли бы вы рассказать, действительно ли столбец с идентификационными данными является первичным ключом? Для инструментов ORM полезно иметь столбец идентификатора на таблицах. Но есть и другие побочные эффекты, такие как случайная двойная вставка.Идентификационная колонка в качестве основного ключа
Благодаря Найн
Ключи IDENTITY являются хорошей практикой для сгенерированных на стороне сервера ключей, в средах, где у вас нет репликации или слияния тяжелых данных. Как они реализованы, они не позволяют дублировать в одной таблице, поэтому не беспокойтесь об этом. Они также имеют преимущество минимизации фрагментации в таблицах, в которых нет большого количества DELETE.
GUID - это обычная альтернатива. У них есть то преимущество, что вы можете создавать их на веб-уровне, не требуя обмена туда-обратно. Однако они больше, чем IDENTITIES, и они могут вызвать фрагментацию экстремальных таблиц. Поскольку они (полу) случайные, вставки распространяются по всей таблице, а не сосредоточены на одной странице в конце.
Чтобы бороться с проблемой GUID фрагментация, используйте GUID в стиле COMB, а не стандартный полностью случайный.На MSSQL существует реализация полу-COMB, которая иногда «достаточно хороша», но не гарантирует вставки в конце страницы во время перезагрузки сервера. Разница в пространстве между int или bigint и GUID (128 бит) в большинстве случаев не стоит беспокоиться. – richardtallent
В дополнение к тому, что он не остается последовательным при перезагрузке сервера (если это так долго), функция NEWSEQUENTIALID также не предотвращает фрагментацию или разбиение страниц; он просто локализует его в одной области до сброса значения. Кроме того, NEWSEQUENTIALID может использоваться только как столбец по умолчанию, поэтому он может генерироваться только на сервере. Кроме того, GUID, сгенерированные таким образом, более угадываются, чем «чистые» GUID - поэтому три преимущества использования GUID по сравнению с IDENTITY не сохраняются с NEWSEQUENTIALID. – RickNZ
Я использую Guid, потому что это действительно помогает, когда я имею дело с распределенными приложениями. Особенно, когда все распределенные экземпляры также должны создавать новые данные.
Тем не менее, я не вижу проблем с автоматическими целыми первичными ключами в простых ситуациях. Я бы предпочел их на самом деле, потому что проще работать непосредственно с SQL-запросами, потому что их легче запомнить.
Да, использование ИДЕНТИФИКАЦИИ INT (или BIGINT) - очень хорошая практика для SQL Server.
SQL Server использует первичный ключ в качестве своего ключа кластеризации по умолчанию, а ключ кластеризации всегда должен иметь следующие свойства:
INT IDENTITY идеально подходит для счета!
Для получения более подробной информации, и особенно некоторая информация, почему GUID в качестве первичного (и, таким образом, кластеризации ключа) является плохо идеи см отличных сообщений Kimberly Tripp по:
Если у вас есть причины, чтобы использовать в качестве идентификатора GUID первичного ключа (например. репликация), то непременно убедитесь, что у вас есть идентификатор INT как ваш кластерный ключ на этих таблицах!
Марк
В отличие от естественного ключа или суррогатного ключа, генерируемого в приложении (привет/вот, Guid и т.д.)? –
См. Http://stackoverflow.com/questions/262547/reasons-not-to-use-an-auto-incrementing-number-for-a-primary-key, поскольку это может быть dup – Rippo