できるだけ多くの処理をホストにプッシュすると、最高のパフォーマンスが得られます。
最初に、ホストで WHERE 句を使用せずに SQL ビューを試します。Crystal Reports のビューを参照する SQL クエリで、WHERE 句と ORDER BY 句を追加します。システムは、クライアント側の SQL をホスト ビューの SQL とマージし、マージされた SQL の最終的な効果を提供します。ストアド プロシージャは必要ないと思います。ビューを使用する方が簡単で柔軟性があります。
以下の手法を使用して、複雑な SQL ビューから余分なパフォーマンスを絞り出しましたが、少し複雑になるため、最適化の作業後に上記の手法で目的のパフォーマンスが得られない場合は使用しません。
もう 1 つの方法は、TABLE ユーザー定義関数を使用して SQL ビューを使用し、レポート パラメータをビューにフィードすることです。ここで、TABLE 関数は一時テーブルからパラメータを取得します。
例:
declare global temporary table SESSION.MY_PARMS (FROM_DATE, TO_DATE) as (
values ( CURRENT_DATE - 30 days, CURRENT_DATE )
) with data with replace
;
create or replace function MY_SCHEMA.MY_PARMS_UDF( )
returns table ( FROM_DATE date, TO_DATE date )
language sql
specific MY_SCHEMA.MY_PARMS_F
not deterministic
disallow parallel
no external action
reads SQL data
called on null input
not fenced
set option dbgview = *source
,commit = *nc
,closqlcsr = *endmod
,datfmt = *iso
,dftrdbcol = *none
,tgtrls = V7R1M0
return
select FROM_DATE, TO_DATE from SESSION.MY_PARMS
;
create or replace view MY_SCHEMA.MY_REPORT_VIEW for system name MY_REPORTV as (
select *
from table( MY_PARMS_UDF( ) )
as MY_PARMS ( FROM_DATE, TO_DATE )
inner join MY_REPORT_DATA R
on R.MY_REPORT_DATE >= MY_PARMS.FROM_DATE
and R.MY_REPORT_DATE <= MY_PARMS.TO_DATE
)
;
Crystal Reports では、各ジョブごとにパラメーター テーブル SESSION.MY_PARMS を作成する必要があります (または、レポート ジョブでパラメーター テーブルを既に作成しており、UPDATE を使用する場合は、UPDATE を使用して内容を更新します)。私は 2002 年以来 Crystal Reports を使用していないので、その部分の実行方法を効率的に手伝うことができません。
次に、Crystal レポートでは、テーブル SESSION.MY_PARMS にプッシュしたレポート パラメータを効果的に使用する、以下のようなクエリを埋め込むことができます。
select * from MY_SCHEMA.MY_REPORT_VIEW
;
テーブル MY_PARMS はライブラリ/スキーマ QTEMP の SESSION 一時テーブルであるため、この設計では複数のユーザーが異なるパラメーターを使用して同時にレポートを実行できます (各ユーザーは個別の JOB と個別の QTEMP ライブラリを使用するため)。
システムはテーブル UDF MY_PARMS_UDF 内のテーブル SESSION.MY_PARMS にレイト バインドします。つまり、そのテーブルを削除して再作成することもでき、VIEW および UDF への次の参照では、テーブル SESSION.MY_PARMS (または新しく更新された行) の新しいコピーが取得されます。 SESSION.MY_PARMS の行を単純に UPDATE する場合)。
レポート パラメータを入力として受け取り、レポートの Crystal Reports に 1 つ以上の結果セットを返す SQL ストアド プロシージャを使用できる可能性は十分にあると思います。ただし、Crystal Reports を長い間使用していないため、SQL ストアド プロシージャへの CALL をサポートしているかどうかは思い出せません。Crystal Reports がパラメータを指定して SQL ストアド プロシージャを呼び出し、プロシージャから 1 つまたは複数の結果セットを受け取ることをサポートしている場合、これは少し簡単です。その場合、パフォーマンスを最大化するために、単一行カーソル処理ではなく、プロシージャーで結果セット指向の SQL を使用して結果セットを構築するようにしてください。
プロシージャーの使用は、UDF およびビュー手法よりも単純ですが、プロシージャーは CALL を使用して呼び出す必要があるため、柔軟性に欠けることに注意してください。ビューは、クエリでテーブルを参照できる場所ならどこでも参照できます。柔軟性の理由から、SQL プロシージャーはほとんど使用せず、代わりに VIEWS と UDF を使用します。また、ほとんどの場合、SCALAR UDF の代わりに TABLE UDF を使用することをお勧めします。これは、クエリ内のより多くの場所で参照でき、クエリ結果セットに列の内容を簡単に含めることができるためです。