私たちの組織では、ユーザー/マネージャーから要求された多数のレポートを作成し、SSRS Webページに公開しています。ロジックを基になるSQLクエリまたはSSRSレポートに入れる必要がありますか？
私たちは、目的の結果を返すSQLプロシージャを作成する傾向があり、そのプロシージャをSSRSデータセットで呼び出します。次に、SSRSを使用してこれを見栄えの良い表に表示し、グループ化などを作成し、グラフをユーザーに提示できるようにするなどの傾向があります。
「年齢」（生年月日および現在の日付から計算される）や「平均売上」（合計額/売上数から計算される）などの「計算列」は、基礎となるSQLプロシージャー。
SSRSには、これらの計算された列をSSRSレポート自体で計算できるようにする多くの関数があります。
私の質問は実際には、「基礎となるデータセットと計算された列を作成してSRRSで作成する利点は何ですか？どんな種類のパフォーマンスヒットがありますか？おそらく考えなければならない他の要因はありますか？
巨大な計算をたくさん行っていない限り、パフォーマンスは大きな問題ではないと思います。
ほとんどのメリットは、レポートデザイナーが、レポートとしてこれらの式を作成するのではなく、データセットにフィールドを作成して再利用可能な式を作成できるようにすることにあります。
これは、維持しやすく、見やすくなりました。 SSRS 2008以降では、各プレースホルダーのフィールド名を見ることができます。これにより、デザイナーは各フィールドの結果がどのようなものになるかを簡単に調整できます。
式を使用する場合、これらのボックスに表示されるのは<<expr>>です。また、この同じ式を複数の場所で使用すると、値の変更方法を決定する場合は、その場所の式を更新する必要があります。計算される。
これは単にDRYの原理を拡張したものです。
ソースとしてリレーショナルデータベースを扱っていて、データセットを返すために実行されているSQLを制御している場合は、一般に、計算やロジックのデータ型変換などをロジックに入れてオフロードすることをお勧めしますデータベースエンジンへの処理は、通常はレポートサーバーよりもはるかに効率的です。
私は通常、レポートを書式設定、レイアウト、グループ化、並べ替えをデータに適用する「プレゼンテーションレイヤー」を目指しています。基になるデータセットを作成するビジネスロジックは、データベース上で実行されるクエリまたはプロシージャにカプセル化されます。 SSRSにはデータの操作を可能にする多くの機能が含まれていますが、通常はデータソース自体がサポートしていない場合にのみ使用します。しかし、動的な機能を備えたレポートを作成している場合（レポートには、レポートでグループ化がどのように行われるかをユーザーが制御できるパラメータがあります）、SSRSで計算を実行してキャッシュをより有効に活用できます。
ありがとう、私が正しく理解していれば、あなたの答えは、データセットを作成する開発者とレポートを作成する別の開発者に基づいているようです。データセットの開発者が、データセットの最後で計算が正確であることを保証できると言うように、その意味では意味があります。 私たちの組織では、データセットはレポート開発者と同じ人物になりがちです – SEarle1986