Увеличьте размер приращения, чтобы соответствовать преимуществу GUID - PullRequest
0 голосов
/ 22 октября 2009

Я думал о внедрении этой системы, но не могу не чувствовать, что где-то есть подвох. Одним из пунктов использования GUID вместо увеличения int является то, что в будущем, если бы вы объединили базы данных, у вас не было бы столкновений по первичному ключу / идентификатору. Однако мой подход заключается в том, чтобы установить размер приращения равным X, где X - это количество серверов, которые я, скорее всего, буду иметь в будущем. Затем на каждом сервере начальное число должно быть приращением по сравнению с начальным числом на предыдущем сервере. Таким образом, во время слияния не будет конфликтов с первичным ключом. Это безопасный, нормальный метод или я сошел с ума :)? Спасибо

Ответы [ 2 ]

1 голос
/ 22 октября 2009

В репликации SQL с несколькими основными устройствами обычно первичные ключи определены как:

  • * 1004 Идентификаторы GUID *
  • int с размером приращения> количество установок
  • int с фиксированным смещением

Недостатком GUID является то, что их может быть сложнее читать и они занимают немного больше места. Однако он позволяет масштабировать до n экземпляров.

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

Пример фиксированного смещения: сайт A начинается с 0, сайт B начинается с 1 000 000, а сайт C начинается с 2 000 000. Эта схема работает нормально, пока один сайт не вставит миллион строк. Эта схема может хорошо работать для автомобилей в автосалонах, где маловероятно, что какой-либо один дилер продаст более 1 000 000 автомобилей, а у вас могут быть сотни представительств в течение срока действия приложения.

0 голосов
/ 22 октября 2009

Что меня пугает, так это то, что вы используете «скорее всего». Вы предполагаете на будущее здесь, и, как правило, это не очень хорошая вещь для таких вещей. Почему бы не использовать GUID?

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

...