我需要能够从SQL Server和Sybase数据库访问这种格式的数据（date, product是关键）。
date, product, dailyProfit, monthlyCumulativeprofit, yearlyCumulativeProfit
目前，我接手的项目有这样的表格，其中dailyProfits得到更新，添加，删除......结果，似乎现有代码损坏了每月累积利润，以及作为年度累积利润。
要克服这个问题并且不必深入挖掘代码+恢复表的完整性，我是否可以拥有如下表：
date, product, dailyProfit
它将接收INSERT，UPDATE，DELETE，并使用某种机制（触发器？或者由于这个较小的表包含平均 300万行？这样的事实而有风险）会给我一个包含累积总和的同步视图，以更自动化和可信任的方式......
您对此有何看法？
答案 0 :(得分：2)
这实际上取决于您使用的数据库和数据使用信息。预先汇总的数据可能会导致过时的信息，因此建议您谨慎行事。只要有可能，应该首选“实时”计算（特别是如果性能不是问题）。
以下是一些可供选择的选项。索引/物化视图（link）或使用M-Olap多维数据集预先聚合信息。
答案 1 :(得分：2)
只要切实可行，请避免存储冗余数据。如果存储单个值和总数，则可能会导致总数可能与各个值的总和不完全匹配。这可能导致神秘的错误，其中读取单个值的函数给出的结果与使用存储的总数的函数不同。如果你很幸运，有人会注意到屏幕A上的值与屏幕B上的值不同，你可以调查并修复它。但是如果事情变得更复杂，就像你使用一组值作为选择标准而另一组用于显示，那么可能没有人会注意到。
保持值同步可能是一个主要的编程问题，取决于关系是什么。如果你很幸运，你可以设置一些触发器，每次添加，更改或删除单个值时自动更新总数，所以至少这只能在一个地方完成。
但这里的关键词是“随时可行”。举个简单的例子：每次用户访问他的银行账户时，他可能都希望看到余额。如果要显示我们必须将每笔交易加起来，可能是多年前打开帐户，这可能是一个性能杀手。
因此，必要时存储冗余总计，但仅限于必要时。如果必须存储冗余总计，请保持尽可能少的级别。我不会存储每日总计，每周总计，每月总计和年度总计。我会尝试为总数选择一个级别并保持不变。就像你可以在飞行中重新计算每日和每周的总数。也许保持每月，然后你可以计算年度加起来12个月。或者也许只是保持年度长期计算，并且所有内容都不会在飞行中计算。这完全取决于您拥有的记录数量以及所需的输出量。但是，每增加一个额外的东西，还有一件事要保持同步，因此还有一个潜在的问题。
答案 2 :(得分：0)
这取决于。如果您经常请求累积总和，那么存储它们是个好主意，因为每次请求计算它们都会占用大量资源。
您可以设置触发器，以便在添加和减少时增加累积值。在更新时，您可以充分更新。
出于同样的原因，互联网论坛通常有每个用户的帖子数，尽管事实上可以根据每个请求计算帖子（这会产生巨大的性能影响）。添加新帖子时触发器会增加计数器，删除帖子时会减少。