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