Я разрабатываю биллинг систему и сейчас перешел к алгоритму ежемесячного снятия денег с аккаунта клиента.

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

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

После снятия денег - "дата следующего снятия денег" меняется на другую дату.

Таким образом в случае возникновения какой-нибудь ошибки(например, кто-то нажмет на Reset в момент работы программы) - на следующий день деньги будут все равно сняты, если вчера что-то не было обработано.

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


Может у кого-то есть идеи по улучшению этого алгоритма?

Для таких случаев и придуманы транзакции.

Цитата(Akina @ 19.1.2005, 13:15)

Для таких случаев и придуманы транзакции.

но тут транзакции я делаю ведь сам.

Admin
Ну и делай... если ты собираешься изменить запись, то твои действия:

1) Проверить наличие временной таблицы. Если она есть, то
1а) Скопировать записи из временной таблицы в основную (при этом затираются имеющиеся в ней записи с тем же ID)
1б) Проверить что все записи скопированы правильно
1в) Удалить временную таблицу
2) Сделать выборку записей, которые подлежат изменению.
3) Скопировать их в отдельную временную таблицу.
4) Произвести изменения.
5) Проверить правильность внесенных изменений.
6) Удалить временную таблицу.

Обязательна ли временная таблица?

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

Даже на серьезных SQL-серверах транзакции организованы именно таким образом.

Цитата(Akina @ 19.1.2005, 14:17)

Вместо создания-удаления таблицы можно в дополнительную таблицу добавлять-удалять копии изменяемых записей.

это для надежности? Для предотвращения одного из 1 000 000 возможности сбоя?

Да.
Впрочем основное назначение таких таблиц - поддержание целостности при каскадных операциях и реализация триггерных операций.