【发布时间】:2010-09-16 11:35:12
【问题描述】:
是在数据库中有一个字段来存储客户帐户余额还是使用视图和查询来生成信息更好。
【问题讨论】:
是在数据库中有一个字段来存储客户帐户余额还是使用视图和查询来生成信息更好。
【问题讨论】:
对于性能,我会说两者。保留所有交易的日志(在单独的表中),但在客户记录中保留一个字段,该字段存储当前余额,当您添加更多交易时会刷新该余额。
【讨论】:
我从事的一个项目我们将当前余额存储在一个字段中,并将所有交易存储在另一个表中,但由于该项目对数据完美 100%(或更好)或时间的重要性级别,我们还将余额的哈希值存储在另一个字段中,每次调用时都会比较哈希值以确保完整性,如果不匹配,则从交易表中重新计算,重新哈希后发送给客户支持部门供审核。
【讨论】:
我认为这取决于很多因素,您访问余额的频率,每次需要时重新计算余额的复杂程度。拥有视图等的开销是多少?
纯粹根据您提供的信息,我会存储该值,因为每次从头开始重新计算它可能会很痛苦。
【讨论】:
“这取决于”。大多数情况下,您希望避免派生数据。但是,在某些情况下,得出的总数是合理的。
例子:
我在一个信用数据库应用程序中工作,其中余额由许多不同的事物和不同的业务规则组成。例如,“余额”实际上是来自不同存储桶的不同余额的总和,例如本金、费用等。
随着交易的发布,它们会根据业务规则分配到不同的存储桶中。费用进入了费用桶。购买、贷方和借方进入本金桶。这些分配和规则会随着时间的推移而发生变化。
想象一下,面对随着时间的推移不断变化的业务规则,动态查询 100,000 个客户余额。这是一个可靠的案例,其中派生值实际上是有意义的。我们维护了一套算法来“倒回”账户并按时间顺序重建余额以用于审计和验证目的,但对于大型集合,您不会想要这样做。
【讨论】:
如果视图和查询为您提供足够快的结果,则不要存储在单独的字段中。
如果速度不够快,请将其存储到单独的字段中。由于该字段将存储冗余信息,因此保持同步非常重要。
【讨论】:
这里的每个人都是对的。它确实取决于。但是您可以通过使用视图来两全其美。听起来您可能有一个相当小的系统,动态计算余额将是最简单的事情。为了简单起见,我将定义一个视图,其中包含您想要的帐户数据(动态计算)。
如果您需要更多的性能,我会设置一个基于触发器的系统来更新主帐户表的余额,然后在后台更新视图,这样您就不需要更改任何内容其他代码。只要确保您对任一查询都使用正确的数据库隔离模式,否则您将遇到麻烦! ;-)
【讨论】:
这取决于您需要访问此信息的频率。如果是偶尔,那我会说继续重新计算。
【讨论】:
使用视图和查询 - 您会惊讶于它的运行速度。
【讨论】: