Couche de séparation de rapports SQL et la couche présentation?

Question

J'utilise SQL Server Reporting Services. La plupart de mes requêtes exécutées sous forme de rapports qui sont simplement exportés en PDF.

Je voudrais savoir quel type de calculs, le cas échéant, devrait faire dans la requête SQL réelle et qui doit être calculée à l'aide du SSRS IDE (Business Intelligence Studio).

Par exemple, si j'ai un rapport des ventes de 12 mois (12 mois) qui exige une moyenne des 3 mois les plus récentes ventes, où devrait-il être moyen calculé?

doit la plupart des calculs / agrégations se faire dans la couche de présentation? Toute exception?

Answer 1

Cela pourrait être regardé de 2 façons:

• où vous mettez la logique métier
• temps donné est nécessaire pour les calculs, où est plus efficace

La réponse à l'une de ces derniers est « ça dépend ». Pour votre exemple d'un rapport de 12 mois qui a également les tendances affichées, si vous avez quelques paramètres qui changent la logique utilisée pour obtenir les données, je serais tenté de faire autant que possible dans la procédure stockée SQL (même la moyennes) et font le rapport assez « stupide » pour afficher uniquement les résultats. Si le rapport est très simple ou la logique est spécifique à ce rapport seulement, puis dans le travail pourrait rapport.

Pour réutilisabilité Je suis favorable à faire les choses dans SQL. Pour vos commandes d'affichage complexe (heatmapping, graphiques, etc.), dans le rapport est probablement mieux.

Answer 2

Gardez la logique du rapport avec le rapport. SQL Server vous donnera les données mais il est préférable de garder une logique personnalisée avec le rapport.

Answer 3

Je resterais loin d'avoir le rapport make la base de données allers-retours pour les calculs. Si votre procédure stockée (s) de regroupement et de commande correspond à votre mise en page du rapport alors SSRS est assez efficace pour faire des calculs agrégés.