Сервер Firebird 2.5.7.27050 Super
Диалект 1

Не могу понять как должен работать Numeric.
У меня он себя ведет идентично Double Precision.
Правильно ли я понимаю, что Numeric это всего лишь представление Double Precision, но...
В какой момент должно происходить "обрезание" хвостов?
Я это не могу получить, как при сохранении данных в Numeric поле, так и при запросах из такого поля.
При операциях сравнения Numeric так же продолжает себя вести, как Double Precision

Вот пример (делаю в IBExpert):

Создаем таблицу
CREATE TABLE TABLE1 (
NUM1 NUMERIC(15,6),
NUM2 NUMERIC(15,6)
);

вставляем следующие значения:
INSERT INTO TABLE1 (NUM1, NUM2)
VALUES (0.012345678901 2 , 0.012345678901 3 );

Т.е. значения отличаются последней цифрой хвоста, которая по идее должна отрезаться в Numeric(15,6)

В гриде IBExpert данные отображаются с отрезанными хвостами после 6-го знака. Все ок.
Но если перевести тип полей в Double Precision, то хвосты появляются.
Т.е. данные сохранились в Numeric с хвостами. Это раз.
Но даже черт с ним, с сохранением. Почему при при операциях сравнения эти хвосты не отбрасываются и учитываются?

Вот пример:
Возвращаем тип полей обратно в Numeric (15,6) (для чистоты эксперимента можно таблицу удалить и создать заново)

Следующий запрос вернет NULL
select * from TABLE1 where NUM1 = NUM2

И следовательно, вот этот запрос вернет строку
select * from TABLE1 where NUM1 <> NUM2

Т.е. последняя цифра в хвосте влияет на сравнение.
Почему так происходит, что я делаю не так?

Мимопроходящий15.12.2017 16:15, VictorIn пишет:
> Не могу понять как должен работать Numeric.
> У меня он себя ведет идентично Double Precision.

именно так как описано в доке.
читай про отличия в диалектах.


Т.е. Numeric в первом диалекте это фикция?
В доке
http://www.ibase.ru/files/firebird/Firebird_2_5_Language_Reference_RUS.pdf
написано:

Firebird предлагает два типа данных с фиксированной точкой: NUMERIC и DECIMAL. В
соответствии со стандартом оба типа ограничивают хранимое число объявленным масштабом
(количеством чисел после запятой). При этом подход к тому, как ограничивается точность для
типов разный: для столбцов NUMERIC точность является такой, «как объявлено», в то время
как DECIMAL столбцы могут получать числа, чья точность, по меньшей мере, равна тому, что
было объявлено.Типы данных
30
Например, NUMERIC(4, 2) описывает число, состоящее в общей сложности из четырёх цифр,
включая 2 цифры после запятой; итого 2 цифры до запятой, 2 после. При записи в столбец с
этим типом данных значений 3,1415 в столбце NUMERIC(4, 2) будет сохранено значение 3,14.

Но ни какого сохранения с "обрезанием" не происходит. Хвосты остаются.
Но самое печальное, что отрезание хвостов не происходит и при операциях сравнения.
Я отдаю себе отчет, что что Numeric что это обертка Double Precision в первом диалекте.
Но я так понимаю, что Numeric только и нужен для того, что бы не использовать всякие промежуточные, грузящие сервер приведения FormatFloat при операциях сравнение. Где то на SQL.ru об этом и написано.

В документации не сказано, что это все не работает для первого диалекта.
В чем тогда смысл Numeic в первом диалекте, в отличии от Double Precision, если его используют?

Симонов Денис,

Dimitry SibiryakovВесь первый диалект - пережиток прошлого, от которого разработчики решили избавиться ещё
20 лет назад. Засунь его обратно в ту могилу из которой достал и перестань заниматься
некрофилией.


Это я понимаю. Просто пришлось древний проект открыть. На третий диалект нет возможности перейти.

Симонов ДенисVictorIn,

я тебе скажу больше NUMERIC и DECIMAL и в 3 диалекте "фикция". Читай внимательней как они хранятся в зависимости от требуемой точности. В 1-м диалекте просто не было 64-битного целого, поэтому пришлось хранить в DOUBLE PRECISION. Всё что делают NUMERIC и DECIMAL это просто хранят точность и масштаб, а реальные операции происходят над типами в которых хранятся значения.

Т.е. Numeric ничего не значит, т.е. это просто description? Для каких целей тогда его вводили в 1-ом диалекте?
Тогда вопрос, есть ли красивый способ отбрасывать хвосты в операциях сравнения в 1-ом диалекте вместо UDF,
аля FormatFloat отcюда?: http://www.ibase.ru/round/

Вижу только Round, но он немного по другому округляет нежели FormatFloat.

kdvдля тех, что это стандарт. А дальше - мэппинг на физические типы. Вы как-то странно читаете документацию, одно читаете, а другое - нет.
Как хранится numeric(8,2)? хранится в integer. Причем, вводимое сначала умножается на 100 (10 во второй степени), потом сохраняется в int. При возврате из сервера - наоборот. Это вот что - "ничего не значит"?

Спасибо! Вы исчерпывающе дали ответ на все мои вопросы!

Да, я изначально понял, что меня ткнули в первый пункт дока
"Dialect 1 is intended solely to allow backward comptibility with legacy databases from very old InterBase versions, v.5 and below"

типа читай между строк, что это только все из-за поддержания стандартна и "хранит как" - такого нету.
Оказывается есть) Но не для моего случая(((

kdv,

Спасибо! Все доходчиво объяснили.