SSRS计算字段与SQL Server存储过程中的算法

时间:2016-05-06 05:09:44

标签: sql sql-server performance stored-procedures reporting-services

我正在设计一个使用存储过程作为数据集的SSRS报告。存储过程目前如下所示:

SELECT
    sq.Name,
    SUM(PassPartA) AS 'TotalPassPartA'
    SUM(PassPartB) AS 'TotalPassPartB'
    COUNT(*) AS 'TotalTests'
FROM 
    (
    -- Sub-query here
    ) AS sq
GROUP BY
    sq.Name

结果将如下所示:

+-------------------------------------------------------+
| Name    | TotalPassPartA | TotalPassPartB | TotalTests|
+-------------------------------------------------------+
| Eddard  |             24 |             23 |        25 |
| Benjen  |              2 |              3 |         4 |
| Lyanna  |             10 |             10 |        10 |
---------------------------------------------------------

这可以从数据库中获取我需要的内容,然后我可以在计算字段中获取报告所需的其他信息,包括算术和逻辑表达式。

报告的一些其他信息示例:

  • PartAPassPercentage = TotalPassPartA / TotalTests
  • PartBPassPercentage = TotalPassPartB / TotalTests
  • IsPartAPassedAt90Percent = PartAPassPercentage> = 0.9
  • IsPartBPassedAt90Percent = PartBPassPercentage> = 0.9
  • PartAMagicNumber = IIF(IsPartAPassedAt90Percent, 1, 0)
  • PartAMagicNumber = IIF(IsPartBPassedAt90Percent, 1, 0) * 2
  • TotalMagicNumber = PartAMagicNumber + PartBMagicNumber + 1

这种方法有效,但我想知道在SQL Server存储过程中,算术和逻辑的“工作”是否更有效。我需要的所有列都可以使用“CASE”或“IF / ELSE”语句来返回所需的内容。

我可能忽略的另一个考虑因素是代码维护。在计算字段或存储过程中完成“工作”有什么好处吗? (这可能仅仅是一个意见/偏好......)

我不熟悉或经验过分别测试结果的性能工具,而且我正在开发具有不错硬件的DEV机器,我认为当部署到具有更好/更差硬件的服务器时性能会更好/更差和其他正在运行的进程。

哪种方法会有更好的表现,是做“工作”的最佳场所。

2 个答案:

答案 0 :(得分:0)

最好去存储过程本身的计算字段。如果您在SSRS中使用计算字段,那么如果数据集很大,则需要一些时间。

我的建议是在存储过程中做得更好。

答案 1 :(得分:0)

简单的事物,例如普通百分比,可以作为报告中的计算列实现。这样,您可以减少数据库实例的网络IO。

然而,对于更复杂的东西,它并不那么明显。试想一下 - 例如:

需要什么样的/大量的工作
  • 其中一些派生列的定义将发生变化(一直发生);
  • 其中一些列的数据可用性将取决于运行报告的特定用户的安全权限;
  • 与上述相同,但配置参数取自用户无法直接访问的其他数据库或服务器。

简而言之,尝试估算什么可以被视为常识和相当静态,什么取决于业务需求,因此可以随着时间的推移而发展。