DataConnection と TypedDataTable の使用
多くのシナリオでは、 DataConnection を使用すると、 TypedDataTable を使用するよりもパフォーマンスが向上し、メモリ消費が少なくなります。 ただし、DataConnection の使用に一定の制限があるため、場合によっては TypedDataTable が必要になる場合があります。 他の場合、 TypedDataTable を 使用すると、 DataConnection を使用するよりもパフォーマンスが向上する場合があります。 このトピックでは、正しいアプローチを選択するために考慮する必要がある条件と要因について説明します。
DataConnection より TypedDataTable が適している場合
次の場合は、DataConnection ではなく TypedDataTable を使用します。
データを変更する必要があるが、テーブルに主キーがない場合。 DataConnection を使用してデータを変更するには、主キーが必要です。 したがって、主キーがない場合は、 TypedDataTable が唯一の実行可能なアプローチです。
Note
ルール エンジンは 、TypedDataTable のメモリ内の値のみを更新します。 変更が永続的になるかどうかは呼び出し元によって異なります。
選択度が高い場合。つまり、ルール条件として指定されたテストに大半のテーブル行が合格する場合。 この場合、 DataConnection は多くの利点を提供せず、 TypedDataTable よりもパフォーマンスが悪くなる可能性があります。
テーブルのサイズが小さい場合。通常これには、行数が 500 未満のテーブルが該当します。 ただし、この値は、ルール図形およびルール エンジンで使用可能なメモリによって異なる場合があります。
ルール連鎖の動作がルール セットで予想されている場合。 DataConnection で Update 関数を呼び出すことはサポートされていませんが、ヘルパー メソッドを使用してルールで DataConnection.Update を呼び出すことができます。 ルール チェーンが必要な場合は、 TypedDataTable を選択することをお勧めします。
テーブルの 1 つまたは複数の列に、ルールに不要なデータが大量に格納されている場合。 その例としては、イメージ (大量のデータ)、名前、日付などが列に格納される、イメージ データベースが挙げられます。 イメージが不要な場合は、ルールに必要な列だけを選択した方が効果的です。 たとえば、"SELECT Name, Date from TABLE" などのクエリを発行する方が、 DataConnection を使用するよりも効率的です。
TypedDataTable を使用して、多数のルールで同じデータベース行を必要とするか更新する場合、行はすべてのルール間で共有され、条件が同じ場合 (Table.Column == 5 など)、条件の評価を最適化できます。 DataConnection では、一般に、DataConnection を使用するルールごとにクエリが生成されます。 行は再使用されますが (テーブルに主キーがある場合)、同じデータを毎回取得する複数のクエリが生成されることがあります。
TypedDataTable より DataConnection が適している場合
次の場合は、TypedDataTable ではなく DataConnection を使用します。
テーブルには多数の行が含まれていますが、選択度は低くなります。ルールの条件を満たす行の割合はごくわずかです。
サイズの大きなデータベース テーブルが 1 つしかなく、ルールで使用されるその他のオブジェクトには、少数のインスタンスしか含まれていない場合。 最悪の場合は、データベースに対して実行されるクエリの数が、ルールで使用されるその他すべてのインスタンスの結果と等しくなります。
ルールが論理積条件だけで構成され、データベース テーブル以外のオブジェクトがこれらのルールで使用される場合。