在数据库中创建一个存储客户帐户余额的字段或使用视图和查询来生成信息是否更好。
答案 0 :(得分:8)
为了表现,我会说两者。记录所有事务(在单独的表中),但在客户记录中维护一个字段,该字段存储当您添加更多事务时刷新的当前余额。
答案 1 :(得分:7)
我工作过的一个项目我们将当前余额存储在一个字段中,并将所有事务存储在另一个表中,但由于该项目对数据的重要程度是完美的100%(或更好)或时间,我们还在另一个字段中存储了余额的哈希值,每次调用时都会对哈希值进行比较以确保完整性,如果不匹配则将其从事务表中重新计算,然后重新哈希,然后发送给客户支持部。审查。
答案 2 :(得分:3)
我认为这取决于很多因素,您访问余额的频率,每次需要时重新计算它的复杂程度。有视图等的开销是什么?
纯粹从你所提供的信息来看,我会将价值存储为每次从头开始重新计算,这可能是一种痛苦。
答案 3 :(得分:3)
“这取决于”。通常,您希望避免派生数据。但是,有些情况下,派生的总数是合理的。
案例:
我参与了一个信用数据库应用程序,其中余额由许多不同的东西组成,并且随着时间的推移不同的业务规则。例如,“余额”实际上是来自不同桶的不同余额的总和,例如委托人,费用等。
在发布交易时,根据业务规则将它们分配到不同的存储桶。费用去了费用桶。购买,信用和借记转到主要桶。这些分配和规则可能会随着时间的推移而发生变化。
想象一下,面对不断变化的业务规则,即时查询100,000个客户余额。这是一个可靠的案例,其中派生值实际上是有意义的。我们维护了一组算法来“回放”帐户并按时间顺序重建平衡以用于审计和验证目的,但是对于大型集合来说,这并不是你想做的事情。
答案 4 :(得分:2)
如果视图和查询为您提供足够快的结果,则不要存储在单独的字段中。
如果速度不够快,请将其存储到单独的字段中。由于此字段将存储冗余信息,因此保持其同步非常重要。
答案 5 :(得分:2)
这里的每个人都是对的。它确实依赖。但是,通过使用视图,您可以充分利用这两个世界。听起来你可能有一个相当小的系统,动态计算余额将是最容易的事情。为了简单起见,我将定义一个具有您想要的帐户数据(动态计算)的视图。
如果您需要更多性能,我会建立一个基于触发器的系统,用于将余额更新到主帐户表,然后在后台更新视图,这样您就不需要更改任何其他代码。只要确保您使用正确的数据库隔离模式进行任一查询,否则您将遇到麻烦! ; - )
答案 6 :(得分:0)
这将取决于您需要访问此信息的频率。如果它偶尔出现,那么我会说继续并重新计算它。
答案 7 :(得分:0)
使用视图和查询 - 您会对它的运行速度感到惊讶。