SQL Server уникальный идентификатор против целого числа

Question

Я изучаю ASP.net и использую систему членства.Когда он автоматически генерировал таблицы, я был очень удивлен, увидев, что он использует тип поля с именем «uniqueIdentifier» в качестве первичного ключа, когда в течение многих лет я использовал целочисленное поле, установленное как идентификатор, который автоматически увеличивается.

В чем разница (если вообще имеется) этих двух методов и почему .NET, по-видимому, поддерживает поле уникального идентификатора?

Спасибо за любую информацию!

Том

Answer 1

Тип uniqueidentifier является типом Guid SQL (соответствующий тип BCL System.Guid). В принципе, направляющие представляют собой случайное 128-битное число, которое должно быть уникальным.

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

Answer 2

Какая разница (если вообще есть) между этими двумя методами

для одного уникального идентификатора составляет 16 байтов, в то время как int составляет 4 байта. Если у вас есть URL-адрес типа

http://bla.com? UserID = 1

Вы можете легко догадаться, что такое чужой ИД пользователя, поэтому вы можете попробовать 2 или 4 и т. Д.

когда вы используете это как UserID C7478034-BB60-4F5A-BE51-72AAE5A96640, это не так просто, и уникальные идентификаторы должны быть уникальными для всех компьютеров

если они используют NEWID() вместо NEWSEQUENTIALID(), тогда они получат фрагментацию и разбиение страницы, взгляните на Рекомендация: не кластеризуйтесь на UniqueIdentifier при использовании NewId

Answer 3

Я бы сказал, что .NET не поддерживает уникальный идентификатор или guid в качестве идентификатора, но эта конкретная реализация (поставщик членства ASP.NET SQL Server) делает. Я подозреваю, что те, кто разрабатывал базу данных, работали с предположением, что использование базы данных не должно быть для сайтов с высоким трафиком, или там, где, вероятно, будут составлены большие отчеты.

Возможно, они пытались избежать каких-либо проблем с интеграцией в существующее приложение или в будущем сценарии, когда у вашего приложения был ключ для пользователя. Это может быть ключ любого типа для любого объекта (PK, UserNumber и т. Д.). В реализации ASP.NET SQL Server вероятность столкновения очень мала / приближается к нулю.

Единственный недостаток, который я обнаружил, заключается в том, что наличие кластерного индекса в guid не масштабируется до больших баз данных.

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