BiTel

Имеются две таблицы:
contract_balance и её копия недельной давности contract_balance_bckup.

на текущий момент:


даёт:

2300471.22

и



даёт:

2300371.22

Как видно, за неделю появилась разница в 100 рублей.

Сравниваю кол-во записей в таблицах при (mm=04 and yy=2009) -- одинаковое.

Сравниваю построчно суммы:



Результат:



Дальше интереснее. Если в крайний запрос добавить условие:



и менять число в условии от 0.00001 до 0.1, то кол-во результатов, соотв. этому условию уменьшается от ~300 до 0.


вопрос 1. В связи с каким событием изменилась сумма? напомню, что это происходило не постепенно от 10 рублей до 100, например, а в один день примерно через неделю после сохранения копии таблицы.

вопрос 2. Почему вообще возникает такая ситуация, если столбцы сумм в тблицах имеют тип decimal(10,2)?

(Бухгалтерия не верит в мистику, и потихоньку сооружает для меня эшафот)

Спасибо.

попробуйте прочечать базу

такое случается когда повреждены индексы, в запросах в которых участвует индекс выдается одни результаты, а в которых не участвует - другие...

не понял, что надо сделать?

mysqlchek? сделал. ничего не изменилось


И причём здесь индексы, если я построчно сравниваю таблицы?
берем сумму из одной таблицы и сумму из другой таблицы, вычитаем одну из другой и видим, что разница не равна нулю и отличается от нуля на тысячные или десятитысячные доли единицы, в то время как значения сумм должны быть десятичными числами с двумя знаками после запятой.

ау вас группа у договора не могла поменять? кол-во записей одинаково?

Кол-во записей одинаково, об этом я писал выше. Проверил первым делом, конечно. Но, я всё-таки ещё раз повторю, расхождение по все таблице - это следствие вот этого:



результат: YES

А откуда оно берётся, если в обеих таблицах тип всех слагаемых decimal(10,2) и они соответственно равны?

извиняюсь за возможную глупость, но кто мешает таки сравнить таблицы целиком за апрель и найти те строки где данные не идентичны ?
если разница в 1-2 копейки на куче договоров, то это одно, а если 100 рублей разницы на одном договоре то как бы...

Вы не внимательно читали мой первый пост.

читал, я спрашиваю почему нельзя сравнить "select *", чудес то не бывает, ну или сделать select с условиями на неравенство и увидить воочию как у тебя не будут равны два числа decimal(10,2)

1) Третий sql-запрос в первом посте -- построчное сравнение.
2) Последний sql-запрос, который я приводил -- это то, о чём вы говорите для одного конкретного договора (cid указан явно).
Или я что-то не понимаю?

наверно я чего то не понимаю...
я вижу несхождение по двум агрегирующим выборкам, бог с ними
я вижу выборку где вычисляется разность и результат который дает нули в этой разности
а строки где разность будет не равна нулю есть ?
не будет ли проще сделать выборку с условием на <> что бы увидить сколько будет таких строк и будут ли они вообще

таких строк будет около тысячи. но сравниваемые значения визуально (в формате decimal(10,2)) будут равны, понимаете?
Т.е., например:
select cbb.summa, cb.summa
from cbb, cb
where ...
and cb.summa!=cbb.summa

даст около тысячи вот таких строк:

122.10 122.10

Если попросить показать строки, в которых разница мжду суммами будет больше 1 копейки - таких строк будет 0.
Если попросить показать строки, в которых разница между суммами будет больше 0.001 копейки - то таких строк уже будет пара сотен. Понимаете?

Понимаю. Виновата mysql. Искать схожие проблемы с decimal через гугл пробовали ?

храняться значения в decimal(10,2) но для арифметических операция приводяться к float отсюда и разница

попробуйте исходящий остаток умножить на 100 и отбросить дробную часть а потом уже просумировать

он то "отбросит", а вы ?

мы стараемся считать средствами java в частности класс BigDecimal, а не средствами mysql

у вас не схождение в биллинге вылезло или на базе?

на самом деле достаточно странная проблема, если ошибка только из за округлений float то значит на одном вычислении ошибка может составить лишь копейку, следовательно для разницы в 100 рублей договоров должно быть 10к

а о то что ошибка вылазит в базе это в любом случае не хорошо, отчеты то мы строим по базе, в моем понимании это все же проблема mysql раз она decimal приводит неявно к float на операциях сложения и вычитания

http://dev.mysql.com/doc/refman/5.0/en/ ... float.html ?

жесть, я вообще не врубаюсь в это:



потипу round(x,2) <> round(x,2) и это нормально или как ?

насколько я понял результат round все также число в формате float, а то, что видно в распечатке можно считать округленным форматированным выводом

как вариант можете попробовать проапгрейдить БД, или хотя бы для эксперимента

Зачем мне это?
(Дальше следует небольшая речь о том, что у каждого из нас своя работа и так далее. По причине очевидности, я её опущу.)

Затем, что если вы используете mysql напрямик для построения отчетов, мы ничем кроме советов помочь не сможем....

Хорошо. А как вы делаете на java?
Вы обращаетесь к базе не с суммимрующим запросом, а построчно вытаскиваете значения из базы и средствами java их суммируете, так?
Т.е. если я буду использовать вместо java какой-нибудь, например, php, то такой способ не должен дать такого эффекта?

При работе с числом с плавающей точкой погрешность будет возникать всегда. Во всех языках идет просто округление, поэтому число выглядит нормально.
Когда же вы пытаетесь сравнить
(cb.summa1+cb.summa2-cb.summa3-cb.summa4)-(cb1.summa1+cb1.summa2-cb1.summa3-cb1.summa4)>0.001
то точность результата разности mysql приходится делать также 0.001. А в этом месте уже вылезает погрешность плавающей точки.
Т.е.
(cb.summa1+cb.summa2-cb.summa3-cb.summa4)-(cb1.summa1+cb1.summa2-cb1.summa3-cb1.summa4)=0.00
(cb.summa1+cb.summa2-cb.summa3-cb.summa4)-(cb1.summa1+cb1.summa2-cb1.summa3-cb1.summa4)=0
будет TRUE
(cb.summa1+cb.summa2-cb.summa3-cb.summa4)-(cb1.summa1+cb1.summa2-cb1.summa3-cb1.summa4)>=0.01
false

Разность же ровно в 100 рублей вряд ли погрешность.

В mysql 5.0.7 с полем DECIMAL нормально, а также при использовании FLOAT с округлением (FLOAT(,2)), он автоматически округляет результат суммы.

Если измените конец запроса с
and (cb.summa1+cb.summa2-cb.summa3-cb.summa4)-(cb1.summa1+cb1.summa2-cb1.summa3-cb1.summa4)>0.001
на
and (cb.summa1+cb.summa2-cb.summa3-cb.summa4)!=(cb1.summa1+cb1.summa2-cb1.summa3-cb1.summa4)
должен быть нормальный результат.

Нет, с этого я и начинал, когда искал разницу.

Смотрите:



результат:



Это было кол-во всех строк. Теперь выберем только неравные суммы, как вы посоветоваали:



результат:

А версия mysql какая? Таблицу contract_balance_bckup как создавали? Выполните
SHOW COLUMNS FROM contract_balance
SHOW COLUMNS FROM contract_balance_bckup

Ver 5.0.18


contract_balance:



contract_balance_bckup:

На 5.0.77 при использовании в обоих таблицах decimal (float(,2)) нормально.
Правда тут написано http://dev.mysql.com/doc/refman/5.0/en/ ... float.html что нужно перезагрузить таблицу, не уверен с какой версии у нас таблица contract_balance не передампивалась...

Теоретически такой дамп (из decimal в float) не корректен, т.е. какое-либо значение могло перенестись неверно.
Скажем в 4 байтном float -383130.27 будет -383130.28
Однако в 8 байтный double влезет нормально.