Как структурировать систему баланса счета
Это скорее теоретический вопрос о том, как структурировать архитектуру бухгалтерского баланса пользователя. Для стека мы, вероятно, собираемся использовать Symfony с Doctrine, но я не думаю, что язык наиболее актуален.
Эта проблема:
Нам нужно создать и поддерживать баланс использования для каждого пользователя, чтобы наш оставшийся API использовался для выставления счетов.
Есть три типа счетов:
- Фиксированная цена, например, год / месяц
- Использование после оплаты на основе вызова API.
- Предоплата за использование на основе вызова API.
И их сочетание на одном аккаунте. У вызовов API могут быть разные цены.
Проблема не так проста, как наличие таблицы SQL со столбцом, в котором указано «баланс», и обновите его. Нам нужно регистрировать депозиты и снятие средств со счета и отслеживать каждый вызов API и использование для аудита. Таким образом, это означает, что нам, вероятно, нужна таблица транзакций.
Так что здесь мне нужен совет. Для крупномасштабных приложений, должны ли мы помещать все транзакции пользователей в одну и ту же таблицу, а затем использовать SQL для суммирования баланса по дате? Этот стол может стать огромным через некоторое время. 1 миллион вызовов API = 1 миллион строк.
Возможно, мы могли бы использовать какое-то решение по дебету / кредиту. Чтобы при оплате счета система заказов добавляла положительный баланс на этот счет. И когда выполняется вызов API, он дебетуется в зависимости от цены.
Поскольку у нас есть 3 разные модели выставления счетов, мы можем использовать какой-то тег, который говорит, что «вызов API 1 2 3 является фиксированной ценой, а вызов API 4 5 6 оплачивается за использование».
Если он находится на почте, остаток будет отрицательным.
При каждом запуске биллинга система заказов будет запрашивать у системы баланса, сколько нужно выставить счет.
Любые мысли о том, как структурировать это в здравом уме?
Решение
Вы можете получить больше / лучше ответов, если определите критерии для «вменяемых».
Каноническая модель для этого — действительно таблица транзакций. На мгновение игнорируя проблемы с производительностью, таблица транзакций дает вам ряд преимуществ:
- каждое действие регистрируется, так что вы можете легко увидеть, каким был текущий баланс счета.
- Вы можете легко увидеть, какой баланс был на произвольной точке в прошлом.
- им легко управлять в момент создания транзакции — вы просто вставляете новую строку в таблицу транзакций, вместо того, чтобы выполнять сложную бизнес-логику, чтобы найти баланс текущего пользователя, разработать соответствующую модель ценообразования, а затем изменять баланс, постоянно поддерживая транзакцию / блокировку, чтобы избежать одновременных записей
Поэтому я бы порекомендовал модель «таблица транзакций».
Что касается практических проблем — да, они могут расти довольно быстро. К счастью, базы данных SQL довольно хорошо справляются с большим количеством записей, а в хорошо спроектированной базе данных сотни миллионов строк не представляют особой проблемы. Тем не менее, есть несколько общих стратегий, чтобы избежать огромного количества записей.
Чаще всего вы можете написать процедуру архивирования. Как правило, на счетах с «постоплатой», например, когда клиент оплачивает счет, вы записываете все транзакции, охватываемые этим счетом, в архивную таблицу и заменяете их в таблице транзакций одной строкой. Вы можете сделать обратное для клиента с постоплатой.
Вы также можете разделить логику по времени — одна система, над которой я работал, имела представление под названием «транзакции», которое представляло собой тонкий слой по сравнению со схемой таблиц на основе времени. Каждый месяц ИТ-отдел отбрасывал и заново создавал представление к точке. в таблицах, называемых, например, jan2014, feb2014 и т. д. Они будут заполнять начальный баланс каждого клиента в этих ежемесячных таблицах. Это сработало на удивление хорошо, хотя это неуклюже и требует простоя в конце месяца.
Вы можете разделить по типу клиента — 3 таблицы транзакций, а не одна большая таблица.
Другие решения
Других решений пока нет …
detector