我们正在向我们自己的商店添加一个类似银行的子系统。
我们已经有客户，所以每个人都会得到一种账户，并且可以进行某种交易(添加到帐户中或从中减去)。
所以我们至少需要帐号实体，交易一个和操作将不得不重新计算总余额。
您将如何构建您的数据库来处理这个问题？
是否有任何标准的银行系统必须使用我可以模拟？
顺便说一句，我们在使用 mysql，但也会研究一些 nosql 解决方案以提高性能。
最佳答案
我不认为您需要 NoSQL 来提高速度，因为它不太可能需要太多/任何并行性，并且不确定您可能需要如何非面向模式。除非您开始进入复杂的业务需求以分析数百万客户和数亿笔交易，例如盈利能力，即便如此，无论如何这都是一种数据仓库式问题，您可能不会在您的交易模式上运行如果它变得那么大，第一名。
在关系设计中，我倾向于避免任何需要重新计算余额的设计，因为这样你最终会得到余额修复程序等。 通过适当的索引和足够简单的设计，你可以对交易(正和负)进行简单的 SUM ) 来取得平衡。对交易具有良好一致的符号约定(对于是否添加或减去没有歧义 - 始终添加值)和适当的约束(交易类型数量有限，您可以使用约束指定所有存款为正而所有取款均为负) 你可以让数据库确保没有像负存款这样的异常情况。
即使您想以某种方式缓存余额，您仍然可以依靠这种简单的机制在交易表上增加一个触发器来更新帐户汇总表。
我不太喜欢将这些放在数据库之外的中间层。您的基本会计应该相当简单，它可以在数据库引擎内快速处理，以便执行查询的任何人或应用程序的任何部分都将获得相同的答案，而无需涉及任何客户端代码逻辑。因此，数据库使用约束、触发器和存储过程的组合，在略高于参照完整性的级别上确保完整性(可能不允许关闭非零余额的帐户，可能不允许余额变为负数等)根据需要增加复杂性。我不是在谈论你的所有业务逻辑，只是禁止你认为数据库不应该因为糟糕的客户端编程或未能以正确的顺序做事或使用正确的参数调用事物而进入的低级情况。
在实际银行业务(即 COBOL 应用程序)中，通常数据库模式(通常是非关系和非规范化的——很多这些东西早于 SQL)你会看到很多东西，比如 12 个月的过去余额桶，这些东西在帐户滚动。这些系统使用的一些数据库是分层的。这就是代码真正重要的地方，因为一切都是在代码中完成的。同样，它有点过时并且会遇到各种问题(即可能很像 NatWest 正在经历的事情)，而 NoSQL 是一种回归这种以代码为王的看待事物方式的趋势。我只是倾向于在长时间处理这些事情后思考 - 我不喜欢缓存余额的系统，我不喜欢你真的没有时间点问责制的系统 - 即你在之后忽略交易某个日期，您可以确切地看到某个日期/时间的情况。
我敢肯定有人有类似银行的数据库设计的“标准”模式，但尽管多年来已经建立了几个类似会计的系统，但我并不知道它们 - 账户和交易并不那么复杂，一旦你超越这个概念，一切都得到了高度定制。
例如，在某些情况下，您可能会根据 GAAP 和随时间支付的契约(Contract)按某种时间表确认契约(Contract)的 yield 。在银行业，你有很多与利息相关的事情，资金成本等的利率不同。一旦你开始将业务需求与资金进出会计的基础知识混合起来，一切都会变得独一无二。
关于mysql - 用于存储类银行账户和交易的数据库结构，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11178580/