我正在尝试向站点添加一个非常简单的积分系统。在我的 SQL 数据库中，有一个用于奖励积分的表格，因为管理员可以将用户的积分增加任意数量，以及增加积分的理由。因此，稍微简化一下，此表包含每次管理员奖励积分时获得的积分数、理由和用户 ID。到现在为止还挺好。
但是，网站上有 10 个用户组争夺最高总分。单个用户组的总点数很容易达到 15 000，因为该站点已经有超过 10 000 名成员（诚然，大多数是不活动的）。我想有一个排行榜来显示竞争的用户组和他们的总分，但我担心在实施系统时，每次总结积分会花费太长时间。问题是：我应该在什么级别（如果有的话）将积分汇总保存在数据库中？我是否应该在用户表中为每个用户的总积分设置一个字段，并为用户组排行榜即时汇总这些积分？或者我应该为每次将点添加到单个用户时更新的每个用户组都有一个聚合字段？在实际实施该系统之前，我
这取决于您的硬件，但汇总数千行应该没问题。不过，一般来说，您应该避免将所有用户得分相加，除非您绝对需要。我建议添加一个汇总表，该表将存储每个组的总分，然后每晚运行一个 cron 来验证总分（基本上是求和，然后存储绝对正确的值）。
我建议在您的表格中添加记录奖励积分和奖励原因的表格。此外，分别存储每个用户的总分，并在将其插入日志表和另一个表的同时更新它，其中包含每组的总分。这应该在您的活动水平上运作良好。如果争议太大，您也可以对总组分数进行异步更新，但应该没问题。
老实说，您的聚合仍然可能会在不到一秒的时间内计算出少于 10k 行的数据——您应该让您的操作数据库保持原子性，只存储每个点事务并在查询时计算聚合。如果你真的想要，你可以将你的聚合预先计算到一个物化视图中，但我真的认为你不需要这样做。
您可以使用该子句创建物化视图
refresh fast start with sydate
next sysdate + 1/24
- 让它每小时刷新一次。
您不会有实时聚合数据（它可能会关闭一个小时），但如果数据变得庞大，它可以大大提高聚合查询的性能。就像你现在的数据一样，我什至不会打扰它——你的表现应该没问题。
编辑：不知道为什么我被否决了。我认为这是比将聚合存储在表中更好的解决方案。