Целочисленный первичный ключ для репликации

Question

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

Лучшее, что я могу придумать, - это сначала получить самые важные данные, а затем номер сервера: например. счет-фактура 1 на сервере 1 = 101 счет-фактура 1 на сервере 2 = 102, где не относящаяся к серверу часть (invoiceno) поступает от генератора чисел в БД

алгоритмически: gen_id(INVOICENO_GEN, 1) * 100 + сервер, и вы можете получить номер сервера, посмотрев на значение и математически.

Это оставляет место для 99 серверов, оставаясь коротким и читаемым, и не сталкивается. Используя эту схему и столбец с нормальным целым размером, можно получить максимум строк (21 474 836) или, если используется bigint, много миллиардов.

например, ключи таблицы счетов-фактур будут выглядеть так:

Server 1    
101
201
301
401

Server 2    
102
202
302
402

Итак, мой вопрос: какие-либо критические замечания или недостатки я упустил из виду?

База данных Firebird.

Answer 1

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

Answer 2

Как насчет создания составного первичного ключа?

Определите "ServerID" для установки на каждом сервере, например, 1, 2, 3, 4 и т. Д. Как INT. Затем укажите "InvoiceID" в качестве INT в таблице "Invoice".

Создайте первичный ключ (ServerID,InvoiceID).

Таким образом, у вас есть место для более чем 99 серверов, и вам не нужно манипулировать / вычислять какие-либо идентификаторы или что-то подобное.

Конечно, любая таблица, ссылающаяся на вашу таблицу Invoice, теперь должна также использовать (ServerID, InvoiceID) в качестве внешнего ключа - но я думаю, наличие ServerID везде в ваших таблицах не будет проблемой, если вам нужно будет реплицировать эти таблицы, тоже.

Марк