2009-10-21 4 views
0

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

ответ

1

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

  • GUIDs
  • Int с размером приращению> Количество установок
  • INT в с фиксированным смещением

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

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

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

+0

Привет, Брайангет, спасибо за ответ. Мне удалось следить за тем, чтобы «угадать максимальное количество строк, которые может вставить один экземпляр». Что ты имеешь в виду? – keyboardP

0

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

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

+0

Привет, Дэвид, спасибо за ответ. Я использую GUID на нескольких таблицах, но ради размера и производительности поиска я решил не использовать это все. Из того, что я слышал, тот факт, что GUID не могут быть заказаны, делает запрос медленнее. – keyboardP