Почему первичные ключи генерируются идентификаторами GUID aspnet_regsql?

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

Что касается того, что вы сказали о нескольких миллионах строк данных, с гидами все будет в порядке, если вы всегда просите сервер SQL вернуть одну строку данных. Самая большая проблема будет, когда вы запрашиваете какое-то большое подмножество данных или когда вы пакетно вставляете большое количество строк; Тогда вы, вероятно, будете выполнять много случайных операций ввода-вывода, чтобы получить все строки, соответствующие вашим критериям, или вставить все строки в случайные места, на которые в конечном итоге указывают guids. Кроме того, SQL не нужно «физически перемещать все эти строки вниз, чтобы вставить новую»; Данные хранятся на страницах, и SQL обычно должен изменить данные только на одной странице в файле данных, чтобы вставить строку, возможно, с обновленными парой других страниц, но это не похоже на вставку строки в массивный текстовый файл.

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

Нет ничего плохого в использовании GUID в качестве первичного ключа. Конечно, они могут иметь некоторые недостатки, если их неправильно использовать, но рассмотрим сценарий, в котором у вас есть различные базы данных в магазинах или других торговых точках, и каждую ночь вам нужно брать все данные из каждого места и объединять их в одну. основная база данных в корпоративной. GUID — отличный вариант, потому что вам не нужно беспокоиться о конфликтах идентификаторов.

Каждый из них советовал мне держаться подальше от GUID в качестве первичных ключей при построении базы данных... потому что первичный ключ — это кластеризованный индекс!

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

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

Ниже приведен сценарий SQL из сценария InstallCommon.sql в %WINDIR%\Microsoft.NET\Framework\v4.0.30319:

  CREATE TABLE [dbo].aspnet_Users (
    ApplicationId    uniqueidentifier    NOT NULL FOREIGN KEY REFERENCES [dbo].aspnet_Applications(ApplicationId),
    UserId           uniqueidentifier    NOT NULL PRIMARY KEY NONCLUSTERED DEFAULT NEWID(),
    UserName         nvarchar(256)       NOT NULL,
    LoweredUserName  nvarchar(256)       NOT NULL,
    MobileAlias      nvarchar(16)        DEFAULT NULL,
    IsAnonymous      bit                 NOT NULL DEFAULT 0,
    LastActivityDate DATETIME            NOT NULL)

   CREATE UNIQUE CLUSTERED INDEX aspnet_Users_Index ON [dbo].aspnet_Users(ApplicationId, LoweredUserName)
   CREATE NONCLUSTERED INDEX aspnet_Users_Index2 ON [dbo].aspnet_Users(ApplicationId, LastActivityDate)

Обратите внимание, что столбец первичного ключа (UserId) создается с помощью инструкции PRIMARY KEY NONCLUSTERED, а индекс таблицы CLUSTERED создается как составной индекс по ApplicationId и LoweredUserName.