Каково повышение производительности Последовательного Гуида по стандартному Гуиду?

Если Вы потребность для использования последовательных ГУИДОВ SQL Server 2005 может генерировать их для Вас с эти NEWSEQUENTIALID() функция.

Однако , так как основное использование ГУИДОВ должно генерировать ключи (или альтернативные ключи), который не может быть предположен (например, чтобы избежать, чтобы люди, передающие предполагаемые ключи, ДОБРАЛИСЬ), я не вижу, насколько применимый они - то, потому что они так легко предполагаются.

От MSDN:

Важный:
, Если конфиденциальность является беспокойством, не используйте эту функцию. Возможно предположить значение следующего сгенерированного GUID и, поэтому, данные доступа, связанные с тем GUID.

Выезд РАСЧЕСКИ Jimmy Nilsson: тип GUID, где многие биты были заменены подобным метке времени значением. Это означает, что РАСЧЕСКИ могут быть заказаны, и, когда используется в качестве результата первичного ключа в меньшем количестве разделений индексной страницы при вставке новых значений.

он в порядке для использования uniqueidentifier (GUID) в качестве Первичного ключа?

Я не вижу, что потребность в уникальных ключах, чтобы быть отгадываемой или нет, передавая их от веб-UI или в некоторой другой части кажется плохой практикой отдельно, и я не вижу, если у Вас есть проблемы безопасности, как использование гуида может улучшить вещи (если это - использование вопроса реальный генератор случайных чисел с помощью надлежащих crypto функций платформы).
другие объекты покрыты моим подходом, последовательный гуид может быть сгенерирован от кода без потребности в доступе DB (также, если только для Windows), и это уникально во времени и пространстве.
И да, вопрос был поставлен с намерением ответа на него, чтобы дать людям, которые выбрали Guids для их PK способ улучшиться, использование базы данных (в моем случае позволил клиентам выдерживать намного более высокую рабочую нагрузку, не имея необходимость изменять серверы).

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

Как уже сказал Массимогентилини, производительность можно улучшить при использовании UuidCreateSequential (при создании руководств в коде). Но факт, похоже, отсутствует: SQL Server (по крайней мере, Microsoft SQL 2005/2008) использует ту же функциональность, НО: сравнение / порядок Guids различаются в .NET и на SQL Server, что все равно вызовет больше операций ввода-вывода, потому что гиды будут заказаны неправильно. Чтобы правильно сгенерировать направляющие, упорядоченные для сервера sql (упорядочивание), вам необходимо сделать следующее (см. сравнение подробности):

[System.Runtime.InteropServices.DllImport("rpcrt4.dll", SetLastError = true)]
static extern int UuidCreateSequential(byte[] buffer);

static Guid NewSequentialGuid() {

    byte[] raw = new byte[16];
    if (UuidCreateSequential(raw) != 0)
        throw new System.ComponentModel.Win32Exception(System.Runtime.InteropServices.Marshal.GetLastWin32Error());

    byte[] fix = new byte[16];

    // reverse 0..3
    fix[0x0] = raw[0x3];
    fix[0x1] = raw[0x2];
    fix[0x2] = raw[0x1];
    fix[0x3] = raw[0x0];

    // reverse 4 & 5
    fix[0x4] = raw[0x5];
    fix[0x5] = raw[0x4];

    // reverse 6 & 7
    fix[0x6] = raw[0x7];
    fix[0x7] = raw[0x6];

    // all other are unchanged
    fix[0x8] = raw[0x8];
    fix[0x9] = raw[0x9];
    fix[0xA] = raw[0xA];
    fix[0xB] = raw[0xB];
    fix[0xC] = raw[0xC];
    fix[0xD] = raw[0xD];
    fix[0xE] = raw[0xE];
    fix[0xF] = raw[0xF];

    return new Guid(fix);
}

или эта ссылка или эта ссылка .