Несколько столбцов “ID” в базе данных SQL Server?

Что вы собираетесь сделать с GUID? Столбец int identity также будет уникальным в этой таблице. Вам действительно нужна или может понадобиться возможность репликации? Если да, то предпочтительнее ли использовать GUID в вашей архитектуре, чем работать со столбцами идентификации с помощью одной из опций identity range mangement?

Если вам нравятся "симпатичные" ID, сгенерированные с помощью шаблона Active Record, то я думаю, что я бы попытался использовать его вместо GUID. Если вам действительно нужна репликация, то используйте одну из стратегий репликации, подходящую для идентификационных столбцов.

Рассмотрите возможность использования только GUID, но получите свои GUID с помощью NEWSEQUENTIALID (который выделяет последовательные значения и поэтому не имеет таких же проблем с производительностью кластеризации, как метод NEWID ).

Проблема с использованием вторичного ключа INT в качестве индекса заключается в том, что если это адекватный индекс, зачем вообще использовать GUID? Если необходим GUID, как вместо него использовать индекс INT? Я не уверен, нужен ли вам GUID, и если да, то почему: вы выполняете репликацию и / или слияние между несколькими базами данных? И если вам нужен GUID, то вы не указали, как именно вы собираетесь использовать неглобально уникальный индекс INT в этом сценарии.

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

Я думаю, что удобно использовать GUID вместо INT для первичного ключа, если у вас есть вариант использования для этого (например, несколько баз данных) и если вы можете терпеть линейную потерю производительности O (1), вызванную просто использованием большего ( 16-байтовый) (что приводит к уменьшению количества экземпляров индекса на страницу памяти).

Более серьезное беспокойство вызывает то, как использование (случайного) GUID может повлиять на производительность при его использовании для кластеризации. Чтобы противодействовать этому:

• Либо используйте что-нибудь еще (например, один из естественных ключей записи) в качестве кластеризованного индекса, даже если вы все еще используете GUID для первичного ключа

• , либо позвольте кластеризованному индексу быть то же поле, что и первичный ключ GUID, но используйте NewSequentialId () вместо NewId () для выделения значений GUID.

плохо ли вставлять дополнительный искусственный «идентификатор» для кластеризации, поскольку я не уверен, что у меня будет хороший кандидат на естественный идентификатор для кластеризации?

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

Лично я бы пошел так:

внутренне известная идентификационная идентификация для ваш PK (тот, который не известен конечный пользователь, потому что они неизбежно Хотите контролировать это как-то).
Удобный для пользователя «ID», который уникален с Уважение к какому бизнесу (принудительно либо в вашем приложении или как ограничение).
Гидик в будущее, если это когда-либо считается необходимым (вроде бы, если это требуется для репликация).

Теперь по отношению к кластерному индексу, который вы можете или не могут быть запутаны, рассмотрите в этом руководстве от MS для SQL Server 2000 .

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

Если что-то, что я бы предположил, что у вас есть правильный подход, хотя «удостоверение личности пользователя» является самой сомнительной частью - как и в каком месте, чтобы служить.

Дополнение: Я должен положить в обязательную ссылку на (возможно?) Самая читающая статья о теме Кимберли Трипп. http://www.sqlskills.com/blogs/kimberly/post/guids-as-primary-keys-andor-the-clustering-key.aspx

Использование GUID лениво - то есть дба не может быть обеспокоена моделировать его данные правильно. Также он предлагает очень плохое присоединение производительности - как правило, (16-байтовый тип с плохой местностью).

Это плохой дизайн, если я хочу, чтобы иметь GUID столбца как мой типичный первичный ключ, и отдельный, внутр столбец идентификаторов для моей кластерной ID, и в качестве дополнительного бонуса «дружественный пользователь» идентификатор?

Да, это очень плохо - во-первых, вы не хотите более одного «искусственного» ключа кандидата для вашего стола. Во-вторых, если вы хотите, чтобы у вас был удобный идентификатор идентификатора в качестве клавиш, просто используйте тип фиксированной длины, такой как CHAR [8] или двоичный (8) - предпочтительно двоичный в качестве сорта не будет использовать локали; Вы можете использовать 16-байтовые типы, однако вы заметите ухудшение производительности - однако не так плохо, как GUID. Вы можете использовать эти фиксированные типы для создания собственной удобной схемы выделения, которая сохраняет некоторую местность, но генерирует разумные и значимые идентификаторы.

В качестве примера:

Если вы пишете какую-то систему CRM (позволяет сказать, что онлайн страхование котировки), и вы хотите, чрезвычайно удобной для пользователей типа, например страхование цитата эталонным (QR), который выглядит следующим образом «AD Автомобиль MT 122299432 ".

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

Create Table QRLut
{
    bigint bigint_id;
    char(32) QR;
}

Теперь, если моя модель имеет одну таблицу, которая представляет QR и 20 других таблиц с изображением BigInt QR в качестве внешнего ключа - тот факт, что BIGINT используется позволит моему DB хорошо масштабируется - тем шире предикаты в Больше соотношения вызывается на шине памяти - и объем конкуренции на шине памяти определяет, насколько хорошо ваш процессор может быть насыщенным (множественный процессор).

Можно подумать, в этом примере, что можно просто поместить удобный QR в таблице, которая на самом деле представляет собой цитату, однако имейте в виду, что статистика сервера SQL собирается на таблицах и индексах, и вы не хотите, чтобы Сервер принимает кэширование решений на основе удобной QR - поскольку оно огромное и шумное.

Я думаю, что это плохая идея, но я не знаю, плохо ли это по-другому. Помните, что SQLServer автоматически присваивает кластеризованный индекс Первичному ключу. Вы должны будете удалить его после того, как сделаете GUID первичным ключом. Кроме того, вы обычно хотите, чтобы ваш идентификационный столбец был вашим первичным ключом. Поэтому, делая то, что вы говорите, вы запутаете любого, кто читает ваш код, который не смотрит внимательно. Я бы посоветовал вам сделать столбец ID вашим первичным ключом, столбец идентификации, и поместить на него кластерный индекс. Затем сделать свой столбец GUID уникальным ключом, сделав его некластеризованным индексом и не допускающим нулей. Это в аффекте будет делать то, что вы хотите, но будет следовать больше от стандарта.

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

GUID имеет одинаковые характеристики для кластерных индексов как INT Identity столбцов, при условии, что руководства являются последовательными. Существует NewsentialiD , специфичный для SQL Server, но есть также общий алгоритм для создания их, называемого GOB GUID, основанный на сочетании тока dateTime со случайными байтами таким образом, чтобы сохранить большую степень случайности при сохранении. последовательность.

Одна вещь, которую нужно помнить, если вы собираетесь использовать Nibernate в какой-то момент, это то, что Nibernate в родом знает, как использовать стратегию GUID GUID - и Nibernate может даже использовать его, чтобы сделать пакетные вставки, то, что не может быть сделано С int Identity или NewsexentialiD . Если вы вставляете несколько объектов с Nibernate, то будет быстрее использовать стратегию GUID GUID, чем любой из двух других методов.