firebird будет использоваться как локальная копия части оракловой БД. В ней идентификаторы определены как number(38,0). Я понимаю, что за 18 знаков не скоро зайдёт, но рисковать жедания мало.
Вопрос- в firebird'е один путь- char(38), или в нём можно использовать как-нибудь 128-битные числа? Поскольку внедрение этого модуля будет после нового года (а я надеюсь к тому времени резил двойки поспеет), то если это есть только во второй версии, то тоже хорошо...
PS: кстати, что быстрее будет, в т.ч. при работе к клиентом на java (Jaybird) - char(38), или varchar(38)?
PPS: 6 лет работы с interbase, затем 2 года работы с oracle - и вот, частично возрвращаюсь. Всё видиться по-новому :)
Хранение длинных (38 десятичных знаков) идентификаторов
-
Dimitry Sibiryakov
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
Re: Храниние длинных (38 десятичных знаков) идентификаторов
Объяви хоть сто цифр, только будут ли они использоваться, вот в чем вопрос. Объяви в FB столбец как INT64, только при импорте записей сделай на всякий случай проверку на переполнение.alxt писал(а):firebird будет использоваться как локальная копия части оракловой БД. В ней идентификаторы определены как number(38,0). Я понимаю, что за 18 знаков не скоро зайдёт, но рисковать жедания мало.
Ну, в будущем возможно появится и INT128, и INT256, и INT512...alxt писал(а):Вопрос- в firebird'е один путь- char(38), или в нём можно использовать как-нибудь 128-битные числа? Поскольку внедрение этого модуля будет после нового года (а я надеюсь к тому времени резил двойки поспеет), то если это есть только во второй версии, то тоже хорошо...
. В двойке пока только INT64. Функциональность в FB фиксируются на момент выхода релиз-кандидатов, так что с момента выхода FB 2.0 RC1 ничего нового не появилось...
Да это начальник их. Реально программёр. И задумался он как-то, а что будет, когда id-шники вылезут за int64. И сдвинул id на всех тестовых базах. Жучков давили недели двеWildSery писал(а):Кто такие эти тестеры, что за суперличности, которым (кроме Разработчика) доверено руками крутить генераторыalxt писал(а):Да боюсь тестеры меня не поймут. Сдвинуть последовательность до 20-значного числа- их любимое дело
Я понимаю- в новой системе не один генератор на все id (который реально уфигачил у заказчиков за годы в туманные дали), а много и они так не будут скакать, но боюсь посылать всех нафиг
Зря. Возьми да посчитай. 2^64 - это такое число, что если по 1 млн. значений в секунду круглосуточно ежедневно круглогодично получать, то хватит на примерно 584558 лет.alxt писал(а):но боюсь посылать всех нафиг
В связи с чем очень сомневаюсь что когда-нибудь в обозримом будущем понадобятся генераторы бОльшей размерности.
Рядом сидящие товарисчиWildSery писал(а):Зря. Возьми да посчитай. 2^64 - это такое числоalxt писал(а):но боюсь посылать всех нафиг
мне подсказывают- некоторые заказчики сливают данные с филиалов в одну базу, и чтобы не пересекались id они могу поставить в разных филиалах последовательности на разные базовые значения- в одном 10^20, в другом 2*10^20. А запретить использовать возможности Оракла (числа до 10^38-1) мы не можем.Так что дискуссия о необходимости идентификаторов более 2^64 несколько излишняя в данном случае- заказчики не поймут а тестеры не пропустят. Но поскольку локальная база вряд ли будет узким местом (особенно учитывая клиента на Жабе)- то varchar(38) вполне подойдёт, как я понимаю. Надо ж будет только сравнение...
Вот колонки с задолженностями и оплатой я сделаю ограниченными, тут уж без вопросов
))Всем спасибо, я для себя всё выяснил
Re: Хранение длинных (38 десятичных знаков) идентификаторов
Что мешает разбить идентификатор на несколько integer полей?
как например GUID может быть как строкой, так и набором целых...
как например GUID может быть как строкой, так и набором целых...