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

Question

I am designing a SSRS report that uses a stored procedure as the dataset. The stored procedure currently looks like this:

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

The results will look something like this:

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

This gets me what I need from the database, where I can then get additional information needed for the report with arithmetic and logical expressions in calculated fields .

Example of some additional information for report:

• 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

This approach works, but I wonder if doing the "work" of the arithmetic and logic would be more efficient in the SQL Server stored procedure. All of the columns I would need could use "CASE" or "IF/ELSE" statements to return what is needed.

Another consideration that I may be overlooking is code maintenance. Are there any advantages to having the "work" done in the calculated fields or the stored procedure? (This may just be an opinion/preference though...)

I am not familiar or experienced with performance tools to test the results separately, and I am working on a DEV machine with decent hardware, and I would assume performance would be better/worse when deployed to a server with better/worse hardware and other processes running.

Which approach would have better performance and is the best place to do the "work".

Answer 1

It is good to go for calculated fields in the stored procedure itself. If you use calculated fields in the SSRS and it is going to take a little time if the data set is huge.

My suggestion is doing at stored procedure is much better.

Answer 2

Simple things, such as plain percentage, can be implemented as calculated columns in the report. This way you can reduce network IO for your database instance.

With more complex stuff, however, it's not that obvious. Just think - what kind / amount of work will be needed when, for example:

• Definitions of some of these derived columns will change (happens all the time);
• Data availability for some of these columns will become dependant on, say, security permissions of a particular user who is running the report;
• Same as above, but configuration parameters are taken from another database or server to which user should have no direct access.

In short, try to estimate what can be considered common knowledge and fairly static, and what depends on the business requirements, and as such can evolve with time.