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