BiTel

Не соглашусь, contract_balance, а именно идея сохранения конечных финансовых состояний за месяц(вх./исх. остатки, сумма приходов/расходов, и наработка) очень полезна, и удобна. Избыточность есть, но получаемое удобство того стоит!
Если можете предложить более удачное решение, как хранить баланс с сохранением этих состояний, но без перечисленных недостатков, с удовольствием послушаю:)

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

в тему балансов, хотя уже и говорил по многу раз, но все же, свеженький пример очередного фантома:

mysql> select * from contract_balance where cid = 223 and yy = 2009;
+------+----+-----+-----------+----------+---------+--------+
| yy | mm | cid | summa1 | summa2 | summa3 | summa4 |
+------+----+-----+-----------+----------+---------+--------+
| 2009 | 1 | 223 | -15694.00 | 15694.00 | 0.00 | 0.00 |
| 2009 | 2 | 223 | 0.00 | 0.00 | 0.00 | 0.00 |
| 2009 | 3 | 223 | 0.00 | 0.00 | 0.20 | 0.00 |
| 2009 | 4 | 223 | -0.20 | 0.00 | 8743.80 | 0.00 |
+------+----+-----+-----------+----------+---------+--------+
4 rows in set (0.00 sec)

mysql> select * from contract_account where cid = 223 and yy = 2009;
+------+----+-----+-----+------------+
| yy | mm | cid | sid | summa |
+------+----+-----+-----+------------+
| 2009 | 4 | 223 | 1 | 2.11831 |
| 2009 | 4 | 223 | 2 | 0.41739 |
| 2009 | 4 | 223 | 5 | 5714.56000 |
| 2009 | 4 | 223 | 12 | 1345.20000 |
| 2009 | 4 | 223 | 17 | 1681.50000 |
+------+----+-----+-----+------------+
5 rows in set (0.00 sec)

эти 20 копеек убрать из баланса никак уже нельзя, только лезть править руками базу или заниматься фиктивными зачислениями или еще как то

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

Как раз эти фантомы баланса тут и рассматриваются. Эти -20 копеек, потому, что эта запись за апрель у тебя была создана ранее, будущим числом(не в апреле). Если удалить запись

а потом занести платеж, то 20 копеек исчезнут, и всё корректно станет на свои места.

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

ИДЕАЛЬНОЙ БД не существует, у любой есть свои плюсы и минусы...

есть два решения данной проблемы

1) не допускать создание записей с балансом будущими периодами
2) производить пересчет баланса не до ТЕКУЩЕГО месяца как сейчас, а до ПОСЛЕДНЕЙ существующей записи в таблице баланса

До сих пор мы пытались решить проблему первым способом, теперь попробуем вторым.

Незнаю как Вы будете это решать, но дырок в алгоритме быть не должно. Абстрактно, если чтото принимаете за "входные" параметры, то эти входные параметры должны быть "устойчивы", потому как задача эта должна иметь один единственный, точно определённый результат, и естественно, что решение этой задачи целиком зависит от начальных(входных) данных и допущений!

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

Вы в политику не думали податься? Красиво излагаете....

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

мсье телепат ?


вы оба не угадали, особенно странно что не угадал Skn, ибо у меня есть тикет на эту тему где я как мог пытался объяснить принцип возникновения этих багов у _меня_

все элементарно, есть договор, на нем есть абонки, IPN и тп
10 марта приходит "манагер" и заявляет что договор XXX надо времено заблокировать потому что тра-ля-ля-ля-ля
в ответ он получает много мата, но делать нечего, идем в биллинг и блокируем договор, например, статусом

но, ВНИМАНИЕ, в интернете есть такое понятие как мусорный трафик, флуд, сканы и тп, и даже при выключенном физически спутниковом терминале у клиента на его адреса все равно идет этот спам и он считается биллингом, этот трафик и успет накапать за первых 10 дней марта

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

в результате этих дейстий у клиента наработка пропадает, а баланс виснет

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


Так ) требую уточнения терминологии )
СУБД как таковая к теме разговора вообще отношения не имеет и тут не затрагивалась, да есть СУБД которые обязывают стремится к 3НФ, а есть которые относятся к целосности БД либерально, но как бы всегда есть возможность реализовать 3НФ схему в мысквеле и полное месиво в оракле, все в руках програмиста

"БД" какбы не может иметь плюсы и минусы, БД это таблспейс и схема, так что полагаю под "БД" тика подразумевалось СУБД

Я еще раз говорю: понятно что идеальной схемы быть не может, понятно что где то в угоду производительности нужна избыточность базы (да она в любой задаче нужна, для этого даже спец средства придумываюсь аля теже снапшоты), но, если вводится избыточная сущность то либо она апдейтится на тригерах, либо в ее модификации не допускается никто в обход API, а даном случае это должно быть API сопровождающее contract_account и при любых изменениях пересчитавающий contract_balance, соответсвенно напрямую в эти две таблицы модули писАть не должны

P.S. IMHO ;-P

Уважаемый, ты не ознакомился с темой топика:) Расскажу вкратце.
Если ты у себя выполнишь

возможно обнаружишь какоето кол-во записей.
Например у меня:


откуда они? это ведь балансы за следующие месяца, которые ещё не наступили! Если эти записи не удалить, то когда наступит следующий месяц, в моём примере май, то у него входящий остаток так и останется -1125.82. А за апрель у него ещё всяко может случится, и на границе месяца, вх. и исх. остатки не совпадают. Элементарно, Ватсон!

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

В майскуль кажется есть такая фича, чтобы перед INSERT-ом вызывалось событие типа БЕФОРИНСЕРТ и там можно отменить ИНСЕРТ, если проверка не прошла. Это не точно, слышал такое
Кто знает тонкости mysql, поправьте

2 Jimson

Ваши рассуждение про -20коп. в данном случае не верны, так как эти копейки у вас в балансе в столбце входящий остаток, а не в столбце наработка... т.е. они к перерасчету IPN не имеют отношения.

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

Гррррр.... Наработка исчезает после IPN-Источники-Добавить в обработку рассматриваемого месяца, IPN перегружает трафик и делает пересчет, наработка исчезла, а в contract_balance остались записи, почистить их забыли.
Забыли потому что нет централизованного управления данной таблицей, потому что каждый программист реализующий некую фичу должен озаботится так же о чисках и модификациях избыточных таблиц, естественно он все в голове удержать не может и ошибается, забывает.

2 Jimson

Ваш пример рассматривает неточный ВХОДЯЩИЙ остаток на начало месяца, пересчёт не меняет ВХОДЯЩИЙ остаток. Да и тема данная посвящена именно проблеме баланса, связанной с разными вх. и исх. остатками на границе месяца

Вы перерасчет делали в марте и программа делает ПЕРЕРАСЧЕТ до марта исходя из предположения, что в марте НЕ ДОЛЖНО быть записей за АПРЕЛЬ, поэтому и не переносит исходящий остаток марта на входящий остаток апреля.

А управление этой таблицей в достаточной мере централизовано.

я перерасчет за март делал естественно в апреле, а апрель я вообще не перерасчитывал ибо оно мне нафик не уперлось, считается само каждый час
у меня кредитные договора, все, без надобность до 1го числа месяца в биллинг я не лажу, и ничего будущими часлами не считаю, просто таблица contract_balance не чистится если нет услуг которые образовали наработку, иначе говоря они были -> была наработка -> были цифры в contact_balance -> услуги выключили -> счделали пересчет -> contract_account почистился -> contract_balance не почистился, во всяком случае так ведет себя IPN


ну вам виднее )

2 Jimson ваша проблема с перобсчетами IPN исправлена в 4.6, там все перобсчеты вызывают центарлизованной одну функцию .. По поводу будущих переобсчетов в 4.6 , тоже исправили

Аналогичная проблема

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





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

PS: проблему решил тем что положил деньги руками, но это не вариант[/code]

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

Да, что-то меня совсем не радует тот факт что после вчерашней "чистки" сегодня уже 6 новых записей

чистить достаточно в последний день месяца, где то в 23:55

skn, напишите, пожалуйста, как именно чистить рекомендуете

Добавить в крон скрипт выполняющий запрос в последние дни месяца (28-31) в 23:55

ок, спасибо

я склонен думать что это из серии "вырезать гланды через попу автогеном"

http://www.google.ru/search?hl=ru&q=mys ... ore+insert
http://www.java2s.com/Tutorial/MySQL/02 ... rigger.htm

Говорил уже про триггеры, не работал с ними никогда.
Ща пробую, за сегодня разберусь надеюсь) триггером отменять если создание записей за будущий период, так красивее будет.

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

это решение на данный момент

1) перенос остатков до последней существующей записи в балансе, а не только до текущего месяца - реализован, тестируется
2) запрет на создание записей будущими периодами в работе.

При попытке добавления за будущие месяцы, отменяет добавление с ошибкой

Вроде пашет.
PS
Жёстко защищаем "начальные" данные и допущения

работать то работает, а как таблица по API инсертится ?
не заблокирует ли этот тригер нормальные инсерты в процессе работы?
там (в API) точно единичные инсерты идут?
а не какие-нибудь вложенные с субзапросами?