Как правильно ввести склад и финансы (бизнес-логика)?

Question

[Qixing]

Добрый день. Хочу совета по проектированию и ведению учета финансов и склада в интернет-магазине.
Поискал информацию на просторах интернета. Нашел статью неплохую статью на Хабре .
Собственно как я и планировал сделать также

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

Нагрузка - 1000 заказов в неделю, около 5000 операций в неделю .
Для такой нагрузки хватит ли хранить итоговую сумму/склад ежемесячно, может лучше каждую неделю?
Как быть если я нашел ошибку в финансах и сделал редактирование записи месячной давности?
Аналогия будет и со складом товара?

По финансам была еще мысль хранить архив на дату операции.
Плюсы:
- не надо ничего пересчитывать.
- всего 1-2 итерации

Недостатки:
- при исправлении операции из архива ( 7,14, 30 и более дней спустя) жесткий перерасчет?

У кого какой есть опыт построения таких системы и другие алгоритмы подсчета финансов и актуального стока?
P.S. Интересно было бы посмотреть организацию такого сервиса как zenmoney.

Answer 1

[Сергей Протько]

Нагрузка - 1000 заказов в неделю, около 5000 операций в неделю .

Это почти нулевая нагрузка. Просто не парьтесь.

Лучше почитайте про DDD и загоняйтесь в эту сторону.

Comments

[Qixing]

Спасибо. То есть хранить по актуальные цифры по месяцам вполне?

[Сергей Протько]

Qixing: а как это происходит в реальной жизни? Я же не знаю в чем задачи приложения и какую задачу вы пытаетесь решить.

[Сергей Протько]

Qixing: но хранение посчитанных данных и их перерасчет периодический попахивает преждевременной оптимизацией.

[Qixing]

Сергей Протько: По финансам: мне нужно всегда видеть актуальный баланс на 10 счетов. На каждый счет в таблице от 100 000 записей. Если не хранить промежуточные результаты, то чтобы увидеть актуальный баланс на 10 счетов мне придется произвести выборку и подсчет в php в 100 тыс операций x 10 = 1 000 000 операцию за один запрос. Поэтому решение было хранить еще промежуточные балансы на начало каждого месяца для перерасчета. Ну а актуальный хранить сразу в строке со счетом. Из него просто делать + или - .

Answer 2

[Валерий Рябошапко]

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

У Вас стоит задача (насколько я понял) видеть баланс нескольких пользователей в реальном времени (запрашивать его раз в несколько секунд). Мне сложно представить более быстрый метод, чем считывание переменной из оперативной памяти (таблица БД в опер. памяти или Memcached). Хорошо настроенная СУБД может с сопоставимой скоростью извлечь эти данные и с жёсткого диска.

Учитывая запланированную оптимизацию под большие нагрузки, я бы предложил соорудить очередь заказов. Первый пришёл — первый ушёл. Взяли из очереди заказ, переписали переменную с балансом пользователя, взяли следующий заказ. Таким образом подстреливаем двух зайцев: 1) имеем быстрый доступ к балансу пользователя, 2) точно знаем нагрузку на систему (время ожидания в очереди) и заранее добавляем новых исполнителей.

Что касается пересчёт баланса, то Вы, судя по всему, уже всё продумали. Исправляем ошибочную запись, останавливаем обработку очереди, пересчитываем баланс от любой контрольной точки. Контрольные точки записываются по расписанию, так же с остановкой очереди. Частоту записи КТ нужно определять уже на месте, исходя из потребностей системы.

Comments

[Qixing]

Спасибо. Собственно это и хотел услышать. Таким принципом и пользовался, к которому пришел сам еще давно. Но подумал, что может есть другие алгоритмы.

[Валерий Рябошапко]

Qixing, кстати, очередь можно организовать на базе готовых средств вроде RabbitMQ

[Qixing]

Валерий Рябошапко: интересно. Спасибо!

Answer 3

[Nivka]

То, о чем вы пишете, реализовано в 1С Предприятие.

В версии 7 - это прям-таки отдельные файлы БД, начинающиеся с RA* (записи по каждой операции) и RG* подытоги, рассчитываемые каждый месяц (или чаще, смотря какие настройки системы). Они распространенного формата DBF - есть куча просмотрщиков, которые покажут как там внутри устроено.

И в версии 7 и в версии 8 это можно видеть изнутри.
Читайте форумы по 1С 7 - было множество статей как это устроено и как можно усовершенствовать.
В 8 й версии 1С сильно быстро и далеко продвинулась - статьи по разбору ее устройства еще не успевают.

В терминах 1С это называется "Регистр накопления".