Управление идентификацией / первичным ключом на серверах

Question

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

В нашей текущей базе данных для первичного ключа мы используем два столбца типа int, первый столбец - идентификатор, а другой - для описания, на каком сервере вставлена ​​строка. Теперь я хочу не использовать два столбца для первичного ключа, а просто использовать один столбец. Пока у меня есть два способа сделать это:

1. Использовать GUID для моего первичного ключа

   Это обеспечит наличие уникального ключа на любом количестве серверов. Что мне не нравится в этом, так это то, что GUID имеет размер 16 байт, и при использовании для внешнего ключа во многих таблицах он будет тратить пространство. Кроме того, его труднее использовать при написании запросов, и он будет медленнее запрашивать.

2. Используйте int или bigint и вручную укажите начальное значение и значение приращения для каждой таблицы на каждом сервере. Например, если есть два сервера, таблица X на первом сервере будет начинаться с номера 1, а на втором сервере - с номера 2, каждый будет увеличиваться на 2. Таким образом, будет (1,3,5 ,. ..) на первом и (2,4,6, ...) на втором сервере. Преимущество такого дизайна в том, что его проще использовать при написании запросов, он быстрый и использует меньше места для внешних ключей. Плохо то, что мы никогда не знаем, сколько серверов будет работать, поэтому сложнее сказать, какое будет значение приращения. Также сложнее управлять изменением схемы на сервере.

Какова наилучшая практика для управления несколькими серверами, и каков наилучший способ, если таковой имеется, в этом случае в таких ситуациях?

Answer 1

Ваш вопрос хороший, и его часто спрашивают.

С точки зрения технического обслуживания, я бы абсолютно согласился с GUIDS.Они там по причине.В какой-то момент вы можете столкнуться со сложными операциями перемещения и повторной репликации ваших данных, а затем другие опции могут сделать их немного сложнее, чем нужно.различные варианты здесь:

http://msdn.microsoft.com/en-us/library/bb726011.aspx

Что касается части репликации - если все сделано правильно, то никаких реальных головных болей при репликации нет.

Answer 2

Смею советовать против репликации в целом :) это, конечно, больше боли, чем веселья. Если вы можете себе позволить, посмотрите на Sync framework .

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

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

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

Answer 3

Обновление:

Найден более простой / ручной метод здесь . Включает использование НЕ ДЛЯ РЕПЛИКАЦИИ и ошеломляющие начальные значения идентификаторов, как вы упоминали в комментариях.

Оригинал:

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

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

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