我有一个项目可以计算一些有关用户效果的“统计信息”，然后向他们展示。所有这些统计数据最终来自一个记录用户与网站交互的“交互”的大表。目前，所有这些统计数据都是通过查看这些数据来计算的。我们广泛使用持久性缓存来保持这种速度。
我们正在考虑转向“迭代设计”，其中统计值存储在数据库中，并且在记录每次交互时，我们根据交互对每个得分的贡献来更新值，因此我们基本上是迭代地更新值。 （现在我们只是弄脏了缓存）。
我发现迭代设计存在一些问题，因为这意味着我们将这些冗余的，可能不同步的信息存储在我们的数据库中，这使得添加新统计数据变得困难，并且意味着每个交互日志上的工作量也会增加。但好处是它简化了对单个数据库命中的统计查找！
这个迭代设计中的某些东西为我带来了警钟，但我不能否认潜在的节省时间的好处。我应该遵守这种直觉，还是继续做下去？
答案 0 :(得分：1)
当我在进行数据库设计时，尽量避免存储冗余数据。 （毕竟，这是数据库规范化的对象）。计算的列和视图都可以 - 这些由SQL服务器自动管理和更新。就个人而言，在使用DB进行缓存之前，我会倾向于其他途径（SQL查询真的是需要提高性能的部分吗？我可以通过使用SQL视图来简化应用程序中的事情吗？）
当你说操纵数据时，你执行的操作是如此昂贵？你的意思是插入/更新/删除？如果您对统计数据的使用是写密集型的，则可以考虑删除索引以加速数据更改。
答案 1 :(得分：0)
触发器会有所帮助，因为您可以在新数据进入时进行计算，从而导致数据无效。
这只有在读取远高于写入时才有用。如果我为每次读取做2次写操作，那么这将是一个糟糕的设计。
有关您正在做的事情的更多细节会有所帮助
答案 2 :(得分：0)
基于插入计算肯定是要走的路，恕我直言。
为了解决问题，例如，无法立即生成新统计数据（因为您没有计算数据），您可以：
或
根据您的缓存模式，统计信息可能不同步，或者可能不同步。如果是触发器，则立即发生（插入tblFoo更新tblFooStats）;但你可以根据需要检索它。
我认为唯一真正的风险是如上所述：无法立即添加新的统计数据/计算。如果你掩盖这一点，生活应该是相当不错的。