Расчет баланса пользователя с несколькими таблицами затрат - PullRequest
0 голосов
/ 09 июня 2018

Мы создаем SaaS-предложение, в котором пользователь может нести расходы по различным типам транзакций, например:

  • Выполнение телефонных звонков
  • Отправка SMS-сообщений
  • Хранение аудиозаписей

Мы создали нашу систему для хранения затрат на каждую услугу, например, таблица call_audit выглядит следующим образом:

Date       Call ID  Our Cost  User Cost Currency Duration User ID
---------- -------- --------- --------- -------- -------- -------
2018-01-02 sm_123   0.01      0.02      USD      72       us_1

Таблица sms_auditвыглядит так:

Date       SMS ID   Our Cost  User Cost Currency User ID
---------- -------- --------- --------- -------- -------
2018-01-02 sm_123   0.01      0.02      USD      us_1

Тогда есть таблица payment_audit с пользовательскими платежами и возмещениями:

Date       User ID  Amount Currency Type 
---------- -------- ------ -------- ----
2018-01-02 us_1     12     USD      CHARGE
2018-01-02 us_1     -2     USD      REFUND

У нас также есть таблица user со столбцом balance, котораямы уменьшаем, когда пользователь берет на себя вызов, смс стоимость или возврат.Мы увеличиваем его, когда пользователь платит в свою учетную запись (CHARGE, как указано выше).

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

Одним из улучшений является обновление показателя баланса с помощью триггеров, а не в коде.

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

Еще один подход, о котором мы думали, - это иметь таблицу balance_transactions с debit, credit и работой * 1037.* столбец.Это, конечно, приводит к переходным зависимостям между строками, что не очень хорошо, если вы ищете хорошо нормализованную БД.Это также означает, что мы дублируем данные, но в реальном мире это приемлемый компромисс?

1 Ответ

0 голосов
/ 09 июня 2018

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

Однако фактическое решение зависит от частоты, когда вам нужны эти данные.Если вы, например, ежемесячно выбираете все остатки клиентов для выставления счетов, просто не дублируйте их.Но если вы распечатываете баланс после каждой операции клиента, например, в каком-либо подтверждении транзакции (например, в PDF, сгенерированном и отправленном клиенту по электронной почте), вы можете сохранить текущий баланс в форме, которая была представлена ​​клиенту, так как онвладеет доказательством баланса.

...