iBase.ru Forum

firebird будет использоваться как локальная копия части оракловой БД. В ней идентификаторы определены как number(38,0). Я понимаю, что за 18 знаков не скоро зайдёт, но рисковать жедания мало.

Вопрос- в firebird'е один путь- char(38), или в нём можно использовать как-нибудь 128-битные числа? Поскольку внедрение этого модуля будет после нового года (а я надеюсь к тому времени резил двойки поспеет), то если это есть только во второй версии, то тоже хорошо...

PS: кстати, что быстрее будет, в т.ч. при работе к клиентом на java (Jaybird) - char(38), или varchar(38)?

PPS: 6 лет работы с interbase, затем 2 года работы с oracle - и вот, частично возрвращаюсь. Всё видиться по-новому :)

Лично я бы - рискнул.

Dimitry Sibiryakov писал(а):Лично я бы - рискнул.

Да боюсь тестеры меня не поймут. Сдвинуть последовательность до 20-значного числа- их любимое дело

alxt писал(а):firebird будет использоваться как локальная копия части оракловой БД. В ней идентификаторы определены как number(38,0). Я понимаю, что за 18 знаков не скоро зайдёт, но рисковать жедания мало.

Объяви хоть сто цифр, только будут ли они использоваться, вот в чем вопрос. Объяви в FB столбец как INT64, только при импорте записей сделай на всякий случай проверку на переполнение.

alxt писал(а):Вопрос- в firebird'е один путь- char(38), или в нём можно использовать как-нибудь 128-битные числа? Поскольку внедрение этого модуля будет после нового года (а я надеюсь к тому времени резил двойки поспеет), то если это есть только во второй версии, то тоже хорошо...

Ну, в будущем возможно появится и INT128, и INT256, и INT512... . В двойке пока только INT64. Функциональность в FB фиксируются на момент выхода релиз-кандидатов, так что с момента выхода FB 2.0 RC1 ничего нового не появилось...

alxt писал(а):Да боюсь тестеры меня не поймут. Сдвинуть последовательность до 20-значного числа- их любимое дело

Кто такие эти тестеры, что за суперличности, которым (кроме Разработчика) доверено руками крутить генераторы

WildSery писал(а):

alxt писал(а):Да боюсь тестеры меня не поймут. Сдвинуть последовательность до 20-значного числа- их любимое дело

Кто такие эти тестеры, что за суперличности, которым (кроме Разработчика) доверено руками крутить генераторы

Да это начальник их. Реально программёр. И задумался он как-то, а что будет, когда id-шники вылезут за int64. И сдвинул id на всех тестовых базах. Жучков давили недели две
Я понимаю- в новой системе не один генератор на все id (который реально уфигачил у заказчиков за годы в туманные дали), а много и они так не будут скакать, но боюсь посылать всех нафиг

alxt писал(а):но боюсь посылать всех нафиг

Зря. Возьми да посчитай. 2^64 - это такое число, что если по 1 млн. значений в секунду круглосуточно ежедневно круглогодично получать, то хватит на примерно 584558 лет.
В связи с чем очень сомневаюсь что когда-нибудь в обозримом будущем понадобятся генераторы бОльшей размерности.

WildSery писал(а):

alxt писал(а):но боюсь посылать всех нафиг

Зря. Возьми да посчитай. 2^64 - это такое число

Рядом сидящие товарисчи мне подсказывают- некоторые заказчики сливают данные с филиалов в одну базу, и чтобы не пересекались id они могу поставить в разных филиалах последовательности на разные базовые значения- в одном 10^20, в другом 2*10^20. А запретить использовать возможности Оракла (числа до 10^38-1) мы не можем.

Так что дискуссия о необходимости идентификаторов более 2^64 несколько излишняя в данном случае- заказчики не поймут а тестеры не пропустят. Но поскольку локальная база вряд ли будет узким местом (особенно учитывая клиента на Жабе)- то varchar(38) вполне подойдёт, как я понимаю. Надо ж будет только сравнение...

Вот колонки с задолженностями и оплатой я сделаю ограниченными, тут уж без вопросов ))

Всем спасибо, я для себя всё выяснил

int гораздо быстрее char
а ты не умеешь отстаивать свою (РАЗРАБОТЧИКА) точку зрения

Что мешает разбить идентификатор на несколько integer полей?
как например GUID может быть как строкой, так и набором целых...