SSRS 中的多个报告使用相同的存储过程答案

【问题标题】：Multiple reports in SSRS using same stored procedureSSRS 中的多个报告使用相同的存储过程
【发布时间】：2015-06-23 15:55:54
【问题描述】：

我有一个 SSRS 项目，其中多个报告使用相同的存储过程。所有报告都不同（显然），但数据源相同。

例如，一份报告是具有 50 多个字段和 20 多个参数的较大表格交易报告，一份报告是一个参数，而一页报告本质上只是在详细视图中显示一条记录。很少有其他报告与第一个（表格）报告非常相似，但大多数参数是默认和隐藏的，并且它们使用存储过程中的不同字段。

所有这些报告都使用相同的存储过程（比如sp_Transaction），它有 20 多个参数并返回 100 多个字段。存储过程中处理参数的方式是这样的：

(
    ( 
        tblTransaction.TransactionID = @TransactionId
    )
    OR
    (
        @TransactionId IS NULL
        AND
        (
            @DateCreatedDaysRelative IS NULL
            OR
            (CAST(tblTransaction.Created AS DATE)) = CAST(DATEADD(DAY, @DateCreatedDaysRelative, GETDATE() ) AS DATE)
        )
        AND
        (
            (
                @DateStartMonthsRelative IS NULL
                AND @DateEndMonthsRelative IS NULL
            )
            OR
            ( 
                tblTransaction.DateStart <= DATEADD(MONTH, @DateStartMonthsRelative, GETDATE() )
                AND ( tblTransaction.DateEnd >= DATEADD(MONTH, @DateEndMonthsRelative, GETDATE() ))
            ) 
        )
    )
)

AND
(
    tblTransaction.Receipt = @ReceiptRequired
    OR @ReceiptRequired IS NULL
)
AND
(
    @PubID = dbo.tblJournal.PubID
    OR @PubID IS NULL
)

我知道为所有报告使用一个代码很容易维护，但它是一个大型存储过程，它需要大量参数并返回大量字段，并且非报告（使用它）实际上使用其所有参数或字段.

所以我的问题是“拥有一个通用的大代码，其中一半的输入和输出未使用（一次由一个报告）或为每个报告创建单独的存储过程，只需要输入和输出；还是其他类似存储过程但使用动态 sql 的东西？

【问题讨论】：

这闻起来像是一场维护噩梦。您将如何记住此过程的哪个部分与哪个报告相关联？如果你问这个问题，听起来你已经怀疑这不是一个好主意。
当有很多参数和/或名称不清楚时，在 SSRS 中弄乱参数映射可能会更容易一些。也许您只需要将一些更复杂的检查隔离到它们自己的过程或函数中，以便可以共享它们。
我完全同意@onskee！如果您被其他因素强制维护单个脚本，请记住 WITH RECOMPILE 选项可能会提高性能：msdn.microsoft.com/en-us/library/ms190439.aspx

标签： sql sql-server stored-procedures reporting-services ssrs-2012

【解决方案1】：

这不是一个简单的是/否问题。

你必须考虑很多元素，并且像很多其他事情一样，你不应该过度使用它。

我会说坏主意是：

始终使用单独的查询/SP
始终使用相同的查询/SP

在这两个选项之间放置光标（主要是创建新查询或主要利用同一查询）取决于您。

两者都有优点和缺点，在我的脑海中，它们是：

单独查询/SP

专业版：针对仅处理“有用”数据的每个报告的定制查询
CON：如果需要更新（例如更改列名或需要新列），您必须更新 x 个查询，而不仅仅是 1 个

相同的查询/SP

专业版：更新会影响所有报告，因此您的工作量会减少
CON：更新可能会影响所有报告，因此您可能会产生副作用

【讨论】：

大部分同意，我知道使用相同的 SP 有一个更新工作较少的 PRO，但也有一个 CON（除了你上面所说的）：你每次都做不必要的处理/迭代是通用的询问。只是想知道社区的想法。
为了清楚起见，我并不是说拥有 1 个主 SP 是您应该做的事情。有时，一些报告可能足够相似以共享一个 SP，而不同程度足以不使用共享数据集，这就是您希望为 2 个报告使用相同 SP 的时候。如果您不知道要做出哪个选择，请进行其他查询。

【解决方案2】：

这是一个非常简单是/否的问题。这是一个糟糕的、可怕的想法。

维护是一个您不想处理的重要问题，在任何更改后使用所有参数测试每个报告将是一场噩梦，也是引入错误的好方法。

一个同样重要的问题是性能。此 proc 不会以 any 方式扩展。它将无法使用索引，因为 where 子句中有需要对每一行进行评估的函数。（有一些方法可以缓解这个问题，但这只会让代码变得更更少可读）

报告是否经常运行，是否为每次执行重新编译？执行计划不太可能对所有参数都有效，但如果计划被缓存，使用不同参数调用 proc 将以未知方式影响运行时间。（同样，有一些方法可以缓解这种情况，但代码可读性会受到影响）

肯定有理由使用共享数据集和重用存储过程，但是为所有报告使用超级存储过程是一个坏主意。

【讨论】：