我认为这绝对是一个很好的问题.我必须构建具有类似行为的系统 – 特别是当经常访问具有分数的表时(如在您的场景中).这是我对你的建议:
首先,创建一些如下所示的表(我使用的是SQL Server最佳实践,但是如果您认为合适,请将它们命名):
UserAccount UserAchievement
-Guid (PK) -Guid (PK)
-FirstName -UserAccountGuid (FK)
-LastName -Name
-EmailAddress -Score
完成此操作后,继续创建一个类似于以下内容的视图(不,我没有验证过这个SQL,但它应该是一个好的开始):
SELECT [UserAccount].[FirstName] AS FirstName,[UserAccount].[LastName] AS LastName,SUM([UserAchievement].[Score]) AS TotalPoints
FROM [UserAccount]
INNER JOIN [UserAchievement]
ON [UserAccount].[Guid] = [UserAchievement].[UserAccountGuid]
GROUP BY [UserAccount].[FirstName],[UserAccount].[LastName]
ORDER BY [UserAccount].[LastName] ASC
我知道你已经提到了一些关于性能和大量查询的问题,但是如果你构建一个这样的视图,你将不需要多个.我建议不要将其视为物化视图;相反,只需索引您的表,以便您需要的查找(实际上是UserAccountGuid)将实现表中的快速求和.
我将再添加一点 – 如果您的UserAccount表变得庞大,您可以考虑一个稍微更智能的查询,其中包含您需要进行汇总的帐户名称.这样,当您只在页面上显示3-10个用户的信息时,就不会将大量数据集返回到您的网站.我不得不考虑更多关于如何优雅地做到这一点,但我建议远离“IN”语句,因为这将调用表的线性搜索.