BiTel

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

Да, на счет звонков, я вспомнил как решать проблему фантомных x.99999, вы тарифицируете в джава коде оперируя переменными с большой точностью, а в базе у вас float(10,5), так вот когда вы просто пишете в базу число xx.99999999999999 оно у вас транкейтится, а надо писать
"insert .... values (..., round(<variable>, 5), ...)" и фантомные периоды исчезнут.
И так надо делать везде где вы пишите в базу вычисляемые значения с плавающей точкой, в принципе можно везде округлять до ~10 знака, с запасом так сказать, что бы потом не править код когда захочется вместо float(10,5) сделать float(10,6), вообщем главное захватить последнюю цифру в числах с периодом.

P.S. не просмотрите предыдущий пост мой со кринами, а то вторая страница топика пошла, вдруг не заметите

При вставке MySQL не обрезает а округляет. По абонплатам ошибка воспроизвелась, исправляем.


Собственно, а почему сумму не округлять получая ее? Так и сделано сейчас..

Если бы mysql округляла то наверно вы бы не получали при звонке в 2 минуты, по цене 2 рубля стоимость 3.9999 ?


Значит вы пользуетесь числами с низкой точностью, не знаю, но факт фантомов которые характерны компьюторной операции деления чисел с плавающей точкой на лицо.


Я не очень понял этого предложения. Я могу округлить стоимости тех же звонков, но сумма округленных значений (детализация) не будет равна округленной сумме (наработка). В этом вся проблема, в том числе проблема не схождений доводящей абон платы, нельзя вальготно оперировать округлениями где это вздумается когда число отражает деньги.

P.S. по абонке жду новостей, спасибо, пойду пока узнаю у юриста когда он подпишет договор на тп

Со звонками я уже написал, что сделать попробовать. По абонкам - разбираюсь.

Я ответил Для меня это вариант конечно, хотя для меня лично и round при выборке пропрет так как по каждому договору у меня звонков то там 1000 штук максимум будет и эти фантомы просто не доберут до копейки. Но я за истину тут борюсь

мускул округляет ...земените SELECT на UPDATE и мускул сам округлит до размера поля ...

кстати... может быть вырастить версию BGB под постгрес? на больших нагрузках MySQL как-то совсем не айс. не промышленное решение.

_________________
================================
ООО "Подряд" является зарегистрированным пользователем данного аддикта.

Если кто-то даст реальный тест, показывающий значительный скачок производительности постгресса по сравнению с MySQL на простых конкурирующих UPDATE/SELECT по первичному ключу (собственно у нас 90% выборок простые), мы сразу начнем копать в ту сторону.
До тех пор особого смыслу в смене СУБД не вижу.. Ну назвал ее кто-то "промышленной". Во времена выбора нами СУБД у них даже нативной версии под Windows не было.. И объем документации по сравнению с MySQL просто на порядок уступает.

Да ересь это все. Работает на мысквеле и пусть работает, у него только один недостаток на данный момент: мысквел позволяет делать расхлябанную структуру БД, целосности никакой. Если уже и менять базу банных, то на оракл, если это будет необходимо, а менять шыло на мыло это не серьезно.

Если на оракл, то тогда логику всю надо переносить туда

По поводу копейки: Пока придумал в тарифном плане задавать до какого знака округлять стоимость звонка. В базе хранить 5 знаков.

По поводу оракла: Тесты, тесты нужны ) Причем на близких к нашим (множество простых запросов) условиях. Пробовали мы и оракл. Пролетел, насколько помню. Еще и ставить его замучаешься, кучу кнопок тыкать и настраивать потом. На сервере, куда доступ только по ССШ и никакой графики нет в помине - вообще сказка. Правда, потом RPM нашли вроде..

это такая можа сейчас при словах "база данных" сразу вспоминать оракл? можно конечно и по воробъям крупнокалиберным спецбоеприпасом стрелять но, простите, зачем? для биллинга использующего простейшие запросы вполне хватает мускула, ну разве что вариант с переездом на постгрес еще как то можно обсудить (там спец. формат полей для IP адресов и т.д. и т.п.), а оракл ... IMHO, но это слишком, а если учесть его стоимость (про это что-то все как-то забывают) то можно вообще сказать - "в сад!"(с)

Вот тут вопрос сравнения производительности обсасывали

а переводить СУБД бгбиллинга на оракул, ИМО несерьезно. Постгре таки бесплатный, в отличие от оракула, желающего деньгу за свои решения. Да и выигрыш оракул перед Постгрес дает ИМО только при полномасштабном использовании Oracle PL/SQL. Которому, к слову, команда разработчиков из Беркли, нашла достойное применение и в СУБД PostgreSQL, обозвав его PL/pgSQL.


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

_________________
================================
ООО "Подряд" является зарегистрированным пользователем данного аддикта.

MySQL это M$ Exel

И Еще Одно Преимущество PostgreSQL перед MySQL => у PostgreSQL есть AUTO[VACUUM, ANALYZE, garbage collector]. еще бы автобекап сделали - можно было бы ваще не париться

_________________
================================
ООО "Подряд" является зарегистрированным пользователем данного аддикта.