报告中的计算与存储过程中的计算答案

【问题标题】：calculations in the report vs calculation in stored procedure报告中的计算与存储过程中的计算
【发布时间】：2017-12-18 21:10:20
【问题描述】：

我正在生成一份报告，其中有一个计算作为所需列之一：

SELECT
   ....
   sum(SFLI.PLANNEDVOLUME) * PTS.KILOGRAMSPERUNIT as [WEIGHT],
FROM
   ....
GROUP BY
   ....

我团队的另一位开发人员说，最好将计算移到报告中，而不是将其留在存储过程中，因为它会产生错误的执行计划。我做了一些研究，似乎将计算移到报告中可能对大型数据集不利。

所以我的问题是，将计算留在存储过程中是不是超级糟糕？我很确定 SQL Server 足够聪明，可以并行处理，甚至执行计划也不会那么糟糕。我错了吗？

PS：没有分组，我们谈论的是 250k 行，分组产生

【问题讨论】：

这取决于很多...但是您是否测试过在您的环境中哪个更快？另一个考虑因素是代码重用。如果将数据保留为不聚合以便其他应用程序和报告可以以不同方式调用和聚合数据是有意义的，那么就需要考虑。
250 k 行很小。也可以改进糟糕的执行计划。一个糟糕的执行计划并不总是一件坏事。所以向我们展示执行计划，也许我们可以提供帮助。
这里没有一个真正的答案。我坚信表示层应该尽可能薄。考虑以下情况：我有一个客户添加了新的风险评级。他们必须审查、修改和验证数以千计的报告，而我只是将新项目添加到我的映射表中。
数据库旨在处理数据，而报告用于呈现数据。我已经处理过庞大的数据集和计算，很容易导致报告失败，数据库可以更轻松地处理这种方式。因此，根据我 10 多年的经验或报告，除非太简单，否则请始终使用数据库中的数据进行计算。
我们要做的只是“一个糟糕的执行计划”。我会补充说，当通用业务逻辑可以进入数据库时，将其放入报告中是“不好的”

标签： sql-server tsql stored-procedures reporting-services database-performance

【解决方案1】：

将计算移至报告仅意味着 SSRS Web 服务器将通过代码（C？C++？）而不是 SQL 通过数据库引擎优化器运行它来完成工作。如果您要进行大量字符串操作，那么 SSRS 可能比 SQL 做得更快，但在您的情况下，您看起来像是在进行数值计算，除非有人告诉您，否则我肯定会让 SQL 处理你正在让服务器屈服。如果是，您还可以考虑将查询作为夜间批处理运行到数据集市中。正如@scsimon 所说，这实际上取决于每个场景在您的环境中运行的速度，因此您不能依赖同事的经验法则。

就我个人而言，我有很多使用相同或相似数据集的报表，因此在 SQL 中进行计算对我来说更有意义，因为我可以通过更改底层 proc 来更改所有报表。

【讨论】：