Можно ли установить последовательность таблицы на очень большое значение, например, 10 миллионов?

Question

Есть ли какое-либо влияние на производительность или какие-либо проблемы? Причина, по которой я это делаю, заключается в том, что мы делаем некоторую синхронизацию между двумя наборами БД с похожими таблицами, и мы хотим избежать повторяющихся ошибок PK при синхронизации данных.

Answer 1

Да, все в порядке.

Примечание. Если у вас есть проблемы с производительностью, вы можете использовать опцию «CACHE» в «CREATE SEQUENCE»:

"Укажите, сколько значений последовательности база данных предварительно распределяет и хранит в памяти для более быстрого доступа. Это целочисленное значение может иметь 28 или менее цифр. Минимальное значение для этого параметра равно 2. Для циклов, которые циклически значение должно быть меньше количества значений в цикле. Вы не можете кэшировать больше значений, чем поместится в данный цикл порядковых номеров. Следовательно, максимально допустимое значение для CACHE должно быть меньше значения, определенного по следующей формуле: "

(CEIL (MAXVALUE - MINVALUE)) / ABS (INCREMENT)

"Если происходит системный сбой, все значения кэшированной последовательности, которые не были использованы в зафиксированных инструкциях DML, теряются. Потенциальное число потерянных значений равно значению параметра CACHE."

Answer 2

Единственная проблема, с которой мы недавно столкнулись при создании таблиц с очень большими начальными значениями, была, когда мы пытались взаимодействовать с системой, которую мы не контролировали. Эта система, очевидно, считывала наши идентификаторы как поле char (6), поэтому, когда мы отправили строку 10000000, она не сможет записать.

С точки зрения производительности мы не видели никаких проблем с использованием больших идентификационных номеров.

Answer 3

Конечно. То, что вы планируете делать, на самом деле является довольно распространенной практикой. Просто убедитесь, что переменные в вашем клиентском коде, которые вы используете для хранения идентификаторов, достаточно велики (т. Е. Используйте длинные вместо целых)

Answer 4

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

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

Answer 5

Если вы синхронизируете две таблицы, почему бы не изменить величину начального числа / приращения PK, чтобы при добавлении нового PK все было само собой?

Допустим, вам пришлось синхронизировать данные из 10 таблиц пациентов в 10 разных базах данных.
Скажем также, что в конечном итоге все базы данных пришлось синхронизировать в таблице пациентов в штаб-квартире.

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

DB0 10,20,30 ..
DB1 11,21,31 ..
.....
DB9 19,29,39 ..

Когда все объединено, гарантированно не будет конфликтов.

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