也许我不善于谷歌搜索,但我正在设计一套黄金规则和建议来设计与结算相关的数据库。
假设我有一个带有事务的SQL表
transactions(id int, credit float, debit float, billable_account_id int)
基于database normalization的规则,我放弃了在同一个表或其他地方存储和更新每个事务预先计算的每个* billable_account_id *的运行余额的想法,而不管事务表的大小。< / p>
我正在使用Postgres,如果这很重要(尽管主题很常见),而且我不是一个SQL忍者,而是试图在设计上迂腐。
问题:
非常感谢任何参考!
答案 0 :(得分:1)
您可以使用分析函数在大多数数据库中生成运行总计。在Oracle中,类似
SELECT billable_account_id,
SUM( (CASE WHEN credit IS NOT NULL THEN credit
WHEN debit IS NOT NULL THEN -1 * debit
ELSE 0
END) ) OVER (PARTITION BY billable_account_id
ORDER BY transaction_date ) running_total
FROM transactions
如果您没有TRANSACTION_DATE,则可以使用ID,假设您可以保证生成的ID单调递增。
但是,从性能的角度来看,如果不打破OLAP / DSS类型报告的第三个正常形式规范化规则,您可能会想要弯曲,因为人们想要非常频繁地报告总数并且某些帐户很可能有大量的交易。例如,您可能希望创建一个单独的表,其中每个月末的每个BILLABLE_ACCOUNT_ID都有一个期末余额,然后使用分析函数将当前月份的交易添加到上个月的期末余额中。在Oracle中,您可能希望创建一个自动维护运行总计的物化视图。