mysql-用于存储类似银行的帐户和交易的数据库结构

我们正在向自己的商店中添加类似于银行的子系统.

我们已经有客户,因此每个客户都将获得一个帐户,并且可以进行某种交易(添加到帐户或从中减去).

因此,我们至少需要一个帐户实体,一个交易实体和一个业务部门,然后必须重新计算总余额.

您将如何构造数据库来处理此问题？

有没有我可以嘲笑的标准银行系统？

顺便说一句,我们使用的是mysql,但还将查看一些nosql解决方案以提高性能.

解决方法:

我不认为您需要NoSQL来提高速度,因为它不太可能需要太多/任何并行性,并且不确定您可能需要非面向模式的情况.除非您开始着手进行复杂的业务需求以分析成千上万的客户和数亿笔交易,例如获利能力,即使如此,这还是一种数据仓库式的问题,无论如何您都不会在如果它已经变大,则排名第一.

在关系设计中,我倾向于避免使用任何需要重新计算余额的设计,因为这样您最终会得到余额修复程序等.有了适当的索引和足够简单的设计,您可以对事务(正数和负数)进行简单的SUM运算. )以取得平衡.在交易上具有良好的一致符号约定(在加还是减上没有歧义-始终添加值)和适当的约束条件(在交易类型数量有限的情况下),您可以指定约束条件,即所有存款为正,所有提款为负),您可以让数据库确保没有诸如负存款之类的异常情况.

即使您想要以某种方式缓存余额,您仍然可以依靠这种简单的机制,通过在交易表上添加触发器来更新帐户摘要表.

我不喜欢将任何这些放在数据库外部的中间层.您的基本记帐应该相当简单,以便可以在数据库引擎中快速处理它,以便执行查询的应用程序的任何人或任何部分都将获得相同的答案,而无需涉及任何客户机代码逻辑.因此,数据库可以结合使用约束,触发器和存储过程,在比引用完整性略高一点的级别上确保完整性(不能关闭余额为非零的帐户,不允许余额为负等).根据需要增加复杂性的顺序.我并不是在谈论您的所有业务逻辑,只是禁止出现低级情况,您认为数据库永远都不会由于不良的客户端编程或无法按正确的顺序执行操作或使用正确的参数调用操作而进入数据库.

在实际的银行业务(即COBOL应用程序)中,通常数据库模式(通常是非关系式和非规范化的-很多这样早于SQL)您会看到很多事情,例如12个每月的过去余额存储桶,这些存储桶在帐户结转.这些系统使用的某些数据库是分层的.这是代码真正重要的地方,因为一切都在代码中完成.同样,它是一种老式的并且会遇到各种各样的问题(例如,很可能类似于NatWest正在经历的问题),而NoSQL则正朝着这种以代码为王的事物看待的趋势发展.我只是倾向于认为经过很长的时间来处理这些事情-我不喜欢缓存具有余额的系统,我不喜欢那些您确实没有时间点责任制的系统-即您在之后忽略交易特定日期,您可以确切地看到特定日期/时间的情况.

我确定有人具有类似银行的数据库设计的“标准”模式,但是尽管这些年来我已经建立了多个类似会计的系统,但我还不知道它们-帐户和交易并不那么复杂,而且一旦您超出这个概念,一切都变得高度定制.

例如,在某些情况下,您可能会根据GAAP和随时间支付的合同,按某种时间表确认合同上的收入.在银行业中,您有很多与利率相关的事情,这些利率与资金成本等的利率不同.一旦您开始将业务需求与资金进出基础结合在一起,一切就会变得独一无二.

标签：database-design,database-schema,banking,mysql
来源： https://codeday.me/bug/20191101/1981611.html