数据库/应用程序设计 - 何时反规范化？

Question

我正在开发一个需要为帐户存储金融交易的应用程序。

然后需要以多种方式查询此数据。例如，我需要按类别列出单个交易，每月总计。我还需要显示包含期初/期末余额的月度摘要。

在我看来，我可以通过以下方式解决这个问题：

1. 从数据库一致性和规范化的角度来看，这可以建模为简单的事务列表。然后可以在应用程序中计算余额，方法是将每个交易从开头时间加到您希望显示的余额日期。
2. 对此的一个细微变化是以相同的方式对数据建模，但计算数据库服务器上的存储过程中的余额。感谢这与＃1没有太大的不同 - 随着更多数据添加到系统中，这两个问题的执行速度都会变慢。
3. 可以计算月末余额并将其存储在单独的表中（可能由触发器更新）。从数据一致性的角度来看，我并不喜欢这种方法，但它应该更好地扩展。

我无法真正决定采用哪种方式。我应该从“最纯粹的”数据模型开始，只关注性能问题时的性能吗？我是否应该假设性能将成为一个问题并从第一天开始计划？还有其他选择我没想过哪个可以更好地解决这个问题吗？

Answer 1

我会这样看，计算时间越来越长，而且前2-3个月之前的大部分月数都不会改变。这是一个性能问题，由于财务日期每个月都会增长，因此有100％的可能性发生。因此，在设计阶段寻找解决方案不是过早优化，而是智能设计。

我个人赞成只在需要计算时计算这些总数而不是每次查询时计算总数。是的，总计应该根据表格上的触发器进行更新，这会给插入和删除带来轻微的开销。他们将更快地查询选择。根据我的经验，用户往往比更长的选择查询更能容忍稍长的动作查询。总的来说，只要你正确地执行触发，这对于这种数据来说比纯粹的标准化模型更好。从长远来看，只计算已更改的数字将占用更少的服务器资源。

只要所有事务都通过触发器，此模型将保持数据完整性。其中最大的罪魁祸首通常是数据导入，通常绕过触发器。如果您执行这些类型的导入，请确保它们具有模仿触发器代码的代码。还要确保触发器用于插入/更新和删除，并且使用多个记录事务测试它们，而不仅仅针对单个记录。

另一种模式是创建一个按照时间表填充的数据仓库，例如每晚。如果数据可能稍微过时，这很好。如果此合并数据的大多数查询将用于报告，并且不会涉及当前的月/日那么多，那么这将很有效，您可以在SSIS包中进行。