我们正在为我们自己的商店添加类似银行的子系统。
我们已经有客户，因此每个人都会被分配一个帐户，并且可以进行某种交易（添加到帐户或从帐户中减去）。
所以我们至少需要 account 实体、transaction 实体，然后操作必须重新计算总体余额。
你将如何构建你的数据库来处理这个问题？
有没有我可以模拟的标准银行系统？
顺便说一下，我们使用的是 mysql，但也会考虑一些 nosql 解决方案来提高性能。
【问题讨论】：
标签： mysql database-design database-schema banking
我不认为您需要 NoSQL 来提高速度，因为它不太可能需要太多/任何并行性，并且不确定您可能需要多不面向模式。除非您开始处理复杂的业务需求以分析数以百万计的客户和数亿笔交易（例如盈利能力），即便如此，这仍然是一种数据仓库式的问题，您可能不会在您的事务模式上运行如果它变得那么大，第一名。
在关系设计中，我倾向于避免任何需要重新计算余额的设计，因为这样您最终会得到余额修复程序等。通过适当的索引和足够简单的设计，您可以对交易进行简单的 SUM (正负）来取得平衡。在交易上具有良好一致的符号约定（对于是否添加或减去没有歧义 - 始终添加值）和适当的约束（交易类型数量有限，您可以指定所有存款为正数且所有取款为负数的约束条件) 你可以让数据库确保没有像负存款这样的异常情况。
即使您想以某种方式缓存余额，您仍然可以依靠这种在交易表上添加触发器的简单机制来更新帐户汇总表。
我不喜欢将这些放在数据库之外的中间层。您的基本会计应该相当简单，可以在数据库引擎中快速处理，以便执行查询的任何人或应用程序的任何部分都将获得相同的答案，而无需涉及任何客户端代码逻辑。因此，数据库使用约束、触发器和存储过程的组合确保了略高于参考完整性的完整性（可能不允许关闭余额为非零的帐户，可能不允许余额变为负数等），在根据需要增加复杂性的顺序。我不是在谈论您的所有业务逻辑，只是禁止由于客户端编程错误或未能以正确的顺序执行操作或使用正确的参数调用事物而导致您认为数据库永远不应该进入的低级情况。
在真正的银行业务（即 COBOL 应用程序）中，通常是数据库架构（通常是非关系型和非规范化的 - 其中很多东西都早于 SQL），您会看到很多东西，例如 12 个月的过去余额桶，这些信息会更新并且帐户翻转时转移。这些系统使用的一些数据库是分层的。这就是代码真正重要的地方，因为一切都在代码中完成。再一次，它有点过时并且受到各种问题的影响（即可能很像 NatWest 正在经历的事情），而 NoSQL 是一种回归这种以代码为王的看待事物的方式的趋势。我只是倾向于在长时间处理这些事情后思考 - 我不喜欢缓存余额的系统，我不喜欢你真的没有时间点问责制的系统 - 即你在之后忽略交易特定日期，您可以确切地看到特定日期/时间的情况。
我确信有人拥有类似银行的数据库设计的“标准”模式，但尽管多年来构建了多个类似会计的系统，但我不知道它们 - 账户和交易并没有那么复杂，而且只有一次你超越了这个概念，一切都得到了高度定制。
例如，在某些情况下，您可能会根据 GAAP 和按时间支付的合同按某种时间表确认合同收入。在银行业务中，您有很多与利息相关的事情，资金成本等利率不同。一旦您开始将业务需求与资金进出会计的基础知识结合起来，一切都会变得独一无二。
【讨论】：
你没有说你的应用中是否有一个中间层，在 UI 和数据库之间。如果这样做，您可以选择在哪里标记交易并重新计算余额。如果此数据库完全由一个应用程序拥有，您可以将计算移至中间层并仅使用该数据库进行持久化。
Spring 是一个框架，它有一个很好的基于注解的方式来声明事务。它基于 POJO； EJB 的替代方案。它是依赖注入、面向方面编程和优秀库的三足凳。也许它可以帮助您构建和实现您的应用程序。
如果您确实有一个中间层，并且它是用面向对象的语言编写的，我建议您看看 Martin Fowler 的“分析模式”。它已经存在了很长时间，但是关于金融系统的这一章在今天仍然和最初写成时一样好。
【讨论】：