forum.bitel.ru
http://forum.bitel.ru/

Как делить копейку ?
http://forum.bitel.ru/viewtopic.php?f=22&t=1878		 Страница 1 из 1
Автор:  Jimson [ 04 фев 2009, 05:50 ]
Заголовок сообщения:  Как делить копейку ?
Может я щас скажу глупость, но все же... Разве допустимо в биллинговой системе считать доли копеек ? Вы же никогда в жизни потом не сойдетесь как не округляйте, даже если втыкать во все агрегирующие выборки округление (что должно замедлить выборки просто нереально), то все равно в отчетах (детализациях) клиент получит расхождения.

Я щас ковырялся с выборками по воипу и увидел что там цены звонков аля 482.79999
и что с этим делать ?

Я кстати не спешил писать об еще одной баге с округлениями, жду контракта тех поддержки, а то что то даже на баг репорты тоскливо тут ответа от вас ждать....
Вообщем та же пертрушка с округлениями с доводящими абон платами, конкретный пример по январю, доводящая абон плата по модулю IPN
тариф на доводящую абон плату 5717.10, это же значение в npay_add_cost_detail
наработка по IPN (две услуги на модуле) 470.39 + 4677.90
наработка по доводящей абон плате 568.80

вылезла копейка, я выставил абоненту авансом npay_add_cost_detail, а в конце месяца выставил "доплату" на сумму -0.01
круто...
а не выставлять эту копейку нельзя, потом балансы не сойдутся с 1с и прийдется каждый месяц в куче договоров фиктивные платежи городить

а причина проста:
Код:
mysql> select cid, sid, summa from contract_account where cid = 107 and mm = 01 and yy = 2009 and sid in (1,2);
+-----+-----+------------+
| cid | sid | summa      |
+-----+-----+------------+
| 107 |   2 |  470.39191 |
| 107 |   1 | 4677.90430 |
+-----+-----+------------+

эти два числа округляются до 470.39 и 4677.90 оба в меньшую сторону
а при вычислении доводящей абон платы идет агрегирующая выборка, которая дает сумму в 5148.29620 которая уже округляется в большую сторону

приехали

мне всегда казалось что в любой системе работающей с деньгами либо всегда надо использовать транкейт либо после каждой первичной операции сохранять округленное до копеек число, в часности в таблице contract_acoount, как и в log_session и тп, числа надо хранить с точностью не более 2х знаков

я не прав ?
приму советы как выкручиваться...

p.s самый простой способ сделать модифай такого рода столбцов и поменять им тип, проблема в том что непонятно чем это аукнется, и эсперементировать на собственной заднице как то не хочется :(
Автор:  dimOn [ 04 фев 2009, 12:38 ]
Заголовок сообщения: 
А у Вас какая версия? Просто в 4.5 уже бОльшая часть подобных вещей переведена в соответствующий формат, исключающий вышеописанное.
Автор:  dimOn [ 04 фев 2009, 12:39 ]
Заголовок сообщения: 
Впрочем да, в воипе пока по-старому.
Автор:  Jimson [ 04 фев 2009, 12:48 ]
Заголовок сообщения: 
4.5, обновлялся несколько часов назад

P.S. не только в воипе, а и в contract_accounts еще как минимум
Автор:  Администратор [ 04 фев 2009, 14:15 ]
Заголовок сообщения: 
contract_accounts не перевели в копейки, т.к. в нее идут приращение при обсчете в оперативных модулей типа DialUP и приращение может быть меньше копейки.

но при выборке для суммирования в contract_balance каждая запись в contract_account приводится к копейкам а только затем суммируется.

звонки в телефонии тоже в копейках, в voip сделаем тоже.

по доводящей абонплате тоже переделать нужно рассчет.

P.S. Копейки не подходят, когда в базе есть записи, приращения которых возможны менее копейки.

Т.е. грубо говоря, вы же не соможете указать цену байта с точностью до копейки и чтобы человек получил потом распечатку с ценой каждого байта до копеек и чтобы потом сумма билась.
А вот цену звонка уже можно, например. Так вот и делаем, по случаям.
Автор:  Администратор [ 04 фев 2009, 14:16 ]
Заголовок сообщения: 
Округления при выборках добавляют тормозов копейки просто ) Узкое место подобных систем - дисковые операции, а не нагрузка в пару тиков на на один из процессоров который делает миллиарды этих тиков в секунду..
Автор:  Jimson [ 04 фев 2009, 15:20 ]
Заголовок сообщения: 
Администратор писал(а):
P.S. Копейки не подходят, когда в базе есть записи, приращения которых возможны менее копейки.

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

Услуги тарифицируются порционально, разве нет ? Порция для месячной абон платы - месяц, для IPN - месяц (может когда-нибудь реализуете часовую или хотя бы суточную), для диалапа - СЕССИЯ, для телефонии и воипа - звонок.
Порция не может стоит xx рублей и 25.6734 копейки - это абсурд :)

в contract_account же вообще пишутся месяцный нарабки по услугам, как они то могут стоит доли копеек ?

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

На примере телефонии это просто очень заметно, а в других местах не очень.
Звонок по цене 2 рубля в минуту продолжительностью в 2 минуты не может стоить 3.9999 рубля, согласны ? Наверняка согласны. Тоже самое с диалапом, один в один, в тарифе всегда указано с какой точностью ведутся расчеты и я уверен в природе не бывает тарифов "2 копейки за 5 байтов".
Автор:  and [ 04 фев 2009, 15:38 ]
Заголовок сообщения: 
Jimson писал(а):
Администратор писал(а):
P.S. Копейки не подходят, когда в базе есть записи, приращения которых возможны менее копейки.

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

Услуги тарифицируются порционально, разве нет ? Порция для месячной абон платы - месяц, для IPN - месяц (может когда-нибудь реализуете часовую или хотя бы суточную), для диалапа - СЕССИЯ, для телефонии и воипа - звонок.
Порция не может стоит xx рублей и 25.6734 копейки - это абсурд :)

в contract_account же вообще пишутся месяцный нарабки по услугам, как они то могут стоит доли копеек ?

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

На примере телефонии это просто очень заметно, а в других местах не очень.
Звонок по цене 2 рубля в минуту продолжительностью в 2 минуты не может стоить 3.9999 рубля, согласны ? Наверняка согласны. Тоже самое с диалапом, один в один, в тарифе всегда указано с какой точностью ведутся расчеты и я уверен в природе не бывает тарифов "2 копейки за 5 байтов".


Да в природе не бывает таких тарифов! Но наработка считается с точностью до байта! И при стоимости 1 рубль за мегабайт и наработке в даже в 1 Кбайт стоимость оказанных услуг будет 0,000976563 рубля!
Про звонки понятно! там тарификация секунда от минуты это 1/60, Но при цене мегобайта стоимость 1 килобайта 1/1024, вот почему и идуть не целые копейки! Как Вариант округлять сессию до 100 килобайт!
Автор:  Jimson [ 04 фев 2009, 15:43 ]
Заголовок сообщения: 
and писал(а):
Да в природе не бывает таких тарифов! Но наработка считается с точностью до байта! И при стоимости 1 рубль за мегабайт и наработке в даже в 1 Кбайт стоимость оказанных услуг будет 0,000976563 рубля!
Про звонки понятно! там тарификация секунда от минуты это 1/60, Но при цене мегобайта стоимость 1 килобайта 1/1024, вот почему и идуть не целые копейки! Как Вариант округлять сессию до 100 килобайт!

Да я понимаю что байт может стоить долю копеек, и телефония если она операторская считается посекундно и на операторских тарифах цена секунды будет стоит доли копеек по куче направлений.
Но я говорю что ПОРЦИЯ услуги не может иметь стоимость с долями копеек, это бухгалтерски неверно. В часности звонок в межоператорских расчетах продолжительностью 2-3 секунды округляется по цене в ноль, а уж диалапная сессия в принципе имеет стоимость нормальную в отличии от звонков, и там доли копеек полюбому несущественны.

P.S. хотя не, вру, когда мы (в прошлой жизни) гнали трафик десятками миллионов минут на москву со всего земного шарика, то мы считали ее с точностью до 4го знака, иначе там на коротких звонках были бы просто аховые потери, но это часный случай, никто не будет БГБ использовать для операторского телефонного трафика, месный радиус сервер просто разорвет на куски вместе с компутером через 5 минут работы :)
Автор:  and [ 04 фев 2009, 15:56 ]
Заголовок сообщения: 
Jimson писал(а):
and писал(а):
Да в природе не бывает таких тарифов! Но наработка считается с точностью до байта! И при стоимости 1 рубль за мегабайт и наработке в даже в 1 Кбайт стоимость оказанных услуг будет 0,000976563 рубля!
Про звонки понятно! там тарификация секунда от минуты это 1/60, Но при цене мегобайта стоимость 1 килобайта 1/1024, вот почему и идуть не целые копейки! Как Вариант округлять сессию до 100 килобайт!

Да я понимаю что байт может стоить долю копеек, и телефония если она операторская считается посекундно и на операторских тарифах цена секунды будет стоит доли копеек по куче направлений.
Но я говорю что ПОРЦИЯ услуги не может иметь стоимость с долями копеек, это бухгалтерски неверно. В часности звонок в межоператорских расчетах продолжительностью 2-3 секунды округляется по цене в ноль, а уж диалапная сессия в принципе имеет стоимость нормальную в отличии от звонков, и там доли копеек полюбому несущественны.

P.S. хотя не, вру, когда мы (в прошлой жизни) гнали трафик десятками миллионов минут на москву со всего земного шарика, то мы считали ее с точностью до 4го знака, иначе там на коротких звонках были бы просто аховые потери, но это часный случай, никто не будет БГБ использовать для операторского телефонного трафика, месный радиус сервер просто разорвет на куски вместе с компутером через 5 минут работы :)


С точки зрения бухгалтерии может быть Вы и правы! Но с точки зрения АСР нет. АСР это высокоточная система обсчёта услуг! С моей стороны Вы сами можете для себя найти решения! округляя по трафику или же по вызовам скриптов округлять копейки в соответствующих таблицах баз данных!
Но единственное что и в том и другом случае без потерь не обойтись! Так как если Вы купили 1 мегабайт и продали с округлением то у Вас может получиться в зависимости от округления либо меньше либо больше!
Автор:  Администратор [ 04 фев 2009, 16:21 ]
Заголовок сообщения: 
Цитата:
Да я понимаю что байт может стоить долю копеек, и телефония если она операторская считается посекундно и на операторских тарифах цена секунды будет стоит доли копеек по куче направлений.
Но я говорю что ПОРЦИЯ услуги не может иметь стоимость с долями копеек, это бухгалтерски неверно.

Объясните, зачем в бухгалтерии учет сессий? Чем недостаточно просто наработка договора по какой-то услуге в месяц? ПОРЦИЯ - звучит гордо, но слишком неопределенно.
Автор:  Jimson [ 04 фев 2009, 16:46 ]
Заголовок сообщения: 
Администратор писал(а):
Цитата:
Да я понимаю что байт может стоить долю копеек, и телефония если она операторская считается посекундно и на операторских тарифах цена секунды будет стоит доли копеек по куче направлений.
Но я говорю что ПОРЦИЯ услуги не может иметь стоимость с долями копеек, это бухгалтерски неверно.

Объясните, зачем в бухгалтерии учет сессий? Чем недостаточно просто наработка договора по какой-то услуге в месяц? ПОРЦИЯ - звучит гордо, но слишком неопределенно.


Я написал "бухгалтерски неверно", а не в "бухгалтерии неверено" )
Если вы считаете что суммы по диалапу должны быть с долями копеек, пусть будет так, если вы реализуете почасовую тарификацию IPN то пусть тоже будет с долями копеек. Важно то что бы вы понимали что везде где данный тарификатора сводятся к бухлагтерским данным доли копеек должны исчезнуть. В часности в contract_account долям копеек делать нечего однозначно, это наработки по услугам ЗА МЕСЯЦ. Соответсвенно когда одна услуга расчитывает от наработке по другой услуге всегда должны использоваться данные уже округленные до копеек. Иначе говоря нельзя делать выборки типа round(sum(x)), если так делать то будут вылазить фантомы вроде доводящей абон платы.

На счет порций, я вроде объяснил свою точку зрения, а именно что речь идет о том что деталировки по услугам будт отличаться по сумме от наработок так как деталировка выводит сессии/звонки/дни округляя суммы за эти "порции" услуг, а биллинг округление ведет не по этим же саммым "порциям" а по наработке целиком. Ну опять же пример деводящей абон платы: если x = y + z то round(x) не всегда равно round(y) + round(z)

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

Но, то что у вас щас вылазят доли копеек при тарификации звонков с целым количеством минут это проблема алгоритма все таки. У меня щас тарифный план с поминутным округлением, и везде лезут эти .99999
Таких фантомов арифметики с плавающей точкой можно избежать, как точно не скажу, я слишком давно уже не занимаюсь программированием и все забыл.
Автор:  Jimson [ 04 фев 2009, 17:05 ]
Заголовок сообщения: 
and писал(а):
Но единственное что и в том и другом случае без потерь не обойтись! Так как если Вы купили 1 мегабайт и продали с округлением то у Вас может получиться в зависимости от округления либо меньше либо больше!

Для таких ситуаций обычно реализуют скрытую константу которая добавляется перед округлением, опять же это только в телефонии смысл имело когда продается 2-3 миллиона минут при цене 0.2 цента за минуту с посекундной тарификацией (это абсолютно реальные цифры для транзитного оператора телефонии). Но на транзитной телефонии никто никогда не делает деталировок по услугам.

Для любой другой услуги нет таких дешовых "сессий". У вас есть диалап сессии где критична цена сессии с точностью до копейки? не верю.

И вы не правы на счет того что АРС это таррификатор, это не так. Таррификатор это лишь часть АРС и он может работать с любой точностью, но к АРС в целом так же применяются требования по ведению бухгалтерского учета по обсчитываемым услугам, и на стыке между таррификатором и бухгалтерской частью должна быть четкая грань, бухгалтерские алгоритмы не имеют права лазить в данные таррификатора напрямую, если эти данные необходимы, то они должны быть продублированны с округлением с некоторой агрегацией.

например, таррифкатор может таррифицировать каждый flow отдельно и сохранять стоимость с точностью до 10 знака после запятой, но для бухгалтерии эти данные должны быть агрегированы, например, по часам и стоимости сведены к копейкам, и все бухгалтерские алгоритмы должны пользоваться уже этими агрегированныйми данными с целочисленной арифметикой (в копеках)

Преминительно к телефонии, если интерисует возможность таррифицировать по правилам транзитного оператора, единственный вариант это согранять в логе сессий две стоимости, одну округленную другую с точностью до 5-6 знака, а в настройках услуги, например в концигурации модуля VoIP/Phone, указывать какую стоимость модуль будет использовать для ведения наработок по этой услуге
Для клиенских тарифов услуги будут использовать округленную до копеек стоимость звонков, а услуга операторского трафика будет использовать точную сумму и округлять только итогововую сумму за месяц.
Автор:  Администратор [ 04 фев 2009, 17:19 ]
Заголовок сообщения: 
В contract_account нужен пятый знак, чтобы при тарификации RADIUS ом можно было его просто приращивать, избегая каждый раз пересчета суммы путем суммирования каких-то других таблиц.

А для доводящей абонплаты опять же просто нужно сначала округлить, т.к. для суммирования в contract_balance наработки из contract_account округляются до 2го знака. Вы все равно в хелпдеск опишите, там и разберемся с конретным примером.

Звонки в телефонии уже округлили до 2го знака, т.к. иначе в детализации у клиентов не сходится сумма по копейкам с суммой аработки. С VoiceIP и DialUP(VPN) пока непонятно..

С DialUP суммой та же проблема что и с contract_account - нужно приращивать ее по ходу обсчета.
Автор:  Jimson [ 04 фев 2009, 19:50 ]
Заголовок сообщения: 
договор на ТП щас в оформлении у нас, доступ в ХД есть но я там нифига сделать пока не могу, даже счет выписать, так что я щас продублирую на почту проблему

по проблеме я еще круче ситуацию нашел, чистый ТП, без всяких извратов, услуга с 1 числа месяца, ТП тоже, договор тоже, и при этом наработка по услугам абон платы не совпадает с ТП, это просто смех

вы не поверите, но в наработку попала +1 копейка

я уверен таких проблем будет миллион, латаныем дыр проблема не уберется никогда, она будет вылазить то там то там

прикладываю скрины, за эту копейку по госконтракту меня завтра порвут на британский флаг, и уверяю вас, что объяснения о высокоточной АРС вычисляющей замесяц абонку на 1 копейку больше чем указано в тарифе за месяц начальство не устроит :(

Вложения:
mf2.GIF
mf2.GIF [ 18.47 КБ | Просмотров: 14647 ]
mf1.GIF
mf1.GIF [ 15.55 КБ | Просмотров: 14647 ]
Автор:  Jimson [ 04 фев 2009, 19:54 ]
Заголовок сообщения: 
Администратор писал(а):
В contract_account нужен пятый знак, чтобы при тарификации RADIUS ом можно было его просто приращивать, избегая каждый раз пересчета суммы путем суммирования каких-то других таблиц.

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

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

P.S. не просмотрите предыдущий пост мой со кринами, а то вторая страница топика пошла, вдруг не заметите :)
Автор:  Администратор [ 05 фев 2009, 13:08 ]
Заголовок сообщения: 
При вставке MySQL не обрезает а округляет. По абонплатам ошибка воспроизвелась, исправляем.

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

Собственно, а почему сумму не округлять получая ее? Так и сделано сейчас..
Автор:  Jimson [ 05 фев 2009, 14:02 ]
Заголовок сообщения: 
Администратор писал(а):
При вставке MySQL не обрезает а округляет.
Собственно, а почему сумму не округлять получая ее? Так и сделано сейчас..

Если бы mysql округляла то наверно вы бы не получали при звонке в 2 минуты, по цене 2 рубля стоимость 3.9999 ?
Код:
mysql> select round_session_time, min_cost, session_cost from log_session_4_200902 where session_cost <> round(session_cost, 4);
+--------------------+----------+--------------+
| round_session_time | min_cost | session_cost |
+--------------------+----------+--------------+
|                720 |  4.65000 |     55.80001 |
|               1140 | 14.20000 |    269.79999 |
|               1020 | 14.20000 |    241.39999 |
|                720 |  4.65000 |     55.80001 |
|               1320 | 11.07000 |    243.53999 |
|               2040 | 14.20000 |    482.79999 |
|               1680 | 14.20000 |    397.60001 |
|                720 |  4.65000 |     55.80001 |


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

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

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

P.S. по абонке жду новостей, спасибо, пойду пока узнаю у юриста когда он подпишет договор на тп
Автор:  Администратор [ 05 фев 2009, 14:38 ]
Заголовок сообщения: 
Цитата:
Если бы mysql округляла то наверно вы бы не получали при звонке в 2 минуты, по цене 2 рубля стоимость 3.9999 ?

Со звонками я уже написал, что сделать попробовать. По абонкам - разбираюсь.
Автор:  Jimson [ 05 фев 2009, 14:50 ]
Заголовок сообщения: 
Администратор писал(а):
Цитата:
Если бы mysql округляла то наверно вы бы не получали при звонке в 2 минуты, по цене 2 рубля стоимость 3.9999 ?

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

Я ответил :) Для меня это вариант конечно, хотя для меня лично и round при выборке пропрет так как по каждому договору у меня звонков то там 1000 штук максимум будет и эти фантомы просто не доберут до копейки. Но я за истину тут борюсь :)
Автор:  snark [ 05 фев 2009, 19:08 ]
Заголовок сообщения: 
мускул округляет ...
Код:
mysql> SELECT 0.001 + 0.009;
+---------------+
| 0.001 + 0.009 |
+---------------+
|         0.010 |
+---------------+
1 row in set (0.01 sec)
земените SELECT на UPDATE и мускул сам округлит до размера поля ...
Автор:  skandinav [ 05 фев 2009, 21:21 ]
Заголовок сообщения: 
кстати... может быть вырастить версию BGB под постгрес? на больших нагрузках MySQL как-то совсем не айс. не промышленное решение.
Автор:  Администратор [ 11 фев 2009, 10:13 ]
Заголовок сообщения: 
Цитата:
кстати... может быть вырастить версию BGB под постгрес? на больших нагрузках MySQL как-то совсем не айс. не промышленное решение.

Если кто-то даст реальный тест, показывающий значительный скачок производительности постгресса по сравнению с MySQL на простых конкурирующих UPDATE/SELECT по первичному ключу (собственно у нас 90% выборок простые), мы сразу начнем копать в ту сторону.
До тех пор особого смыслу в смене СУБД не вижу.. Ну назвал ее кто-то "промышленной". Во времена выбора нами СУБД у них даже нативной версии под Windows не было.. И объем документации по сравнению с MySQL просто на порядок уступает.
Автор:  Jimson [ 11 фев 2009, 13:55 ]
Заголовок сообщения: 
Да ересь это все. Работает на мысквеле и пусть работает, у него только один недостаток на данный момент: мысквел позволяет делать расхлябанную структуру БД, целосности никакой. Если уже и менять базу банных, то на оракл, если это будет необходимо, а менять шыло на мыло это не серьезно.
Автор:  Victor [ 19 фев 2009, 12:56 ]
Заголовок сообщения: 
Jimson писал(а):
Да ересь это все. Работает на мысквеле и пусть работает, у него только один недостаток на данный момент: мысквел позволяет делать расхлябанную структуру БД, целосности никакой. Если уже и менять базу банных, то на оракл, если это будет необходимо, а менять шыло на мыло это не серьезно.

Если на оракл, то тогда логику всю надо переносить туда :)
Автор:  Администратор [ 20 фев 2009, 13:42 ]
Заголовок сообщения: 
По поводу копейки: Пока придумал в тарифном плане задавать до какого знака округлять стоимость звонка. В базе хранить 5 знаков.

По поводу оракла: Тесты, тесты нужны ) Причем на близких к нашим (множество простых запросов) условиях. Пробовали мы и оракл. Пролетел, насколько помню. Еще и ставить его замучаешься, кучу кнопок тыкать и настраивать потом. На сервере, куда доступ только по ССШ и никакой графики нет в помине - вообще сказка. Правда, потом RPM нашли вроде..
Автор:  snark [ 20 фев 2009, 17:35 ]
Заголовок сообщения: 
это такая можа сейчас при словах "база данных" сразу вспоминать оракл? можно конечно и по воробъям крупнокалиберным спецбоеприпасом стрелять но, простите, зачем? для биллинга использующего простейшие запросы вполне хватает мускула, ну разве что вариант с переездом на постгрес еще как то можно обсудить (там спец. формат полей для IP адресов и т.д. и т.п.), а оракл ... IMHO, но это слишком, а если учесть его стоимость (про это что-то все как-то забывают) то можно вообще сказать - "в сад!"(с)
Автор:  skandinav [ 05 мар 2009, 16:06 ]
Заголовок сообщения: 
Администратор писал(а):
Цитата:
кстати... может быть вырастить версию BGB под постгрес? на больших нагрузках MySQL как-то совсем не айс. не промышленное решение.

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


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

а переводить СУБД бгбиллинга на оракул, ИМО несерьезно. Постгре таки бесплатный, в отличие от оракула, желающего деньгу за свои решения. Да и выигрыш оракул перед Постгрес дает ИМО только при полномасштабном использовании Oracle PL/SQL. Которому, к слову, команда разработчиков из Беркли, нашла достойное применение и в СУБД PostgreSQL, обозвав его PL/pgSQL.
Цитата:
PostgreSQL runs stored procedures in more than a dozen programming languages, including Java, Perl, Python, Ruby, Tcl, C/C++, and its own PL/pgSQL, which is similar to Oracle's PL/SQL. Included with its standard function library are hundreds of built-in functions that range from basic math and string operations to cryptography and Oracle compatibility


MySQL же изначально задумывался как легковесный, быстрый SQL демон для слабонагруженных приложений. что то вроде SQLite.
основная область его применения - слабонагруженные вебприложения.
Автор:  snark [ 05 мар 2009, 16:26 ]
Заголовок сообщения: 
MySQL это M$ Exel :)
Автор:  skandinav [ 13 мар 2009, 18:24 ]
Заголовок сообщения: 
И Еще Одно Преимущество PostgreSQL перед MySQL => у PostgreSQL есть AUTO[VACUUM, ANALYZE, garbage collector]. еще бы автобекап сделали - можно было бы ваще не париться :)
Страница 1 из 1 Часовой пояс: UTC + 5 часов [ Летнее время ]
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/