Separating SQL reporting layer and presentation layer?

Question

I'm using SQL Server Reporting Services. Most of my queries run as reports which are simply exported as PDF.

I'd like to know which type of calculations, if any, should done in the actual SQL query and which should be calculated using the SSRS IDE (Business Intelligence Studio).

For example, if I have a 12 month sales report (12 months) which requires a sales average of the 3 most recent months, where should that average be calculated?

Should most calculations/aggregations be done in the presentation layer? Any exceptions?

Answer 1

This could be looked at in 2 ways:

• where do you put business logic
• given time is needed for calculations, where is more efficient

The answer to either of these is "it depends". For your example of a 12-month report that also displayed trends, if you have a couple of parameters that change the logic used to get the data, I'd be tempted to do as much as possible in the SQL stored procedure (even the averages) and make the report pretty "dumb" to just display the results. If the report is very simple or the logic is specific to that report only, then in the report might work.

For re-usability I favor doing things in SQL. For complex display stuff (heatmapping, graphs, etc.), in the report is probably better.

Answer 2

Keep the logic of the report with the report. SQL Server will give you the data but it is best to keep customized logic with the report.

Answer 3

I would stay away from having the report make roundtrips to the database for calculations. If your stored procedure(s) grouping and ordering matches your report layout then SSRS is pretty efficient at making aggregated calculations.