|
データを効率よく取得するには、必要なデータのみを返す最も効率のよい方法を選択します。ここでは、.NET アプリケーションでデータを取得するときに、システムのパフォーマンスを最適化する方法を説明します。
ADO.NET は ADO.NET データ プロバイダーを使用してデータにアクセスします。.NET の実行時のデータ アクセスは、すべて ADO.NET データ プロバイダーを介して行われます。
ADO.NET の開発ウィザードでは、OLE DB を使用してウィザードのグリッドを埋めていきます。設計時にこれらのウィザードがアクセスするのは OLE DB ですが、生成されたランタイム コンポーネントがデータのアクセスに使用するのは ADO.NET データ プロバイダーです。.NET アプリケーションで OLE DB を介したデータ アクセスを最適化するのは実用的ではありません。代わりに ADO.NET データ プロバイダーを、実行時のすべての作業を行うコンポーネントとして最適化します。
ネットワーク経由で長いデータを取得するのには時間がかかり、リソースも消費するので、特に必要な場合以外は、アプリケーションから長いデータを要求しないようにします。
ユーザーが長いデータを必要とすることはほとんどありません。ユーザーがこのような結果項目の確認を要求する場合は、選択リストに長いデータの列だけを指定して、アプリケーションからもう一度データベースを照会します。このようにすると、平均的なユーザーは、ネットワーク トラフィックのパフォーマンスにさほど影響を与えずに結果セットを取得することができます。
アプリケーションによっては、ADO.NET データ プロバイダーにクエリを送信する前に選択リストを編成しないものもあります(一部のアプリケーションでは、select * from <table name> ...
などの構文を使用します)。長いデータが選択リストに入っていると、アプリケーションが長いデータを結果セットにバインドしていなくても、フェッチ時に長いデータを取得する必要があるデータ プロバイダーもあります。できれば、テーブルの一部の列のみを取得する方法を試してください。
場合によっては長いデータを取得しなければならないことがあります。このような場合でも、一般に 100 KB を超えるような大量のテキストを画面に表示させるのは望ましくありません。
ネットワーク トラフィックを減らしてパフォーマンスを向上させるために、最大行数や最大フィールド サイズの設定を呼び出したり、行サイズやフィールド サイズを制限するほかのデータベース固有のコマンドを呼び出したりして、取得するデータのサイズを扱いやすいサイズまで下げることができます。取得するデータのサイズを下げるもう 1 つの方法は、列のサイズを小さくすることです。データ プロバイダーでパケット サイズを定義できる場合は、必要な最小パケット サイズを指定します。
また、必要な行のみが返されるようにしてください。たとえば、2 列しか必要でないのに 5 列を返すようにしていた場合、不要な列に長いデータが入っていると、パフォーマンスが低下します。
CommandBuilder オブジェクトは SQL ステートメントを生成するには便利だと思われがちです。しかし、これを使用するとパフォーマンスに悪影響を及ぼす恐れがあります。同時処理の制限が原因で、CommandBuilder オブジェクトは効率のよい SQL ステートメントを生成することができません。たとえば、次の SQL ステートメントは Command Builder で作成されたものです。
CommandText:UPDATE TEST01.EMP SET EMPNO = ?, ENAME = ?, JOB = ?, MGR = ?, HIREDATE = ?, SAL = ?, COMM = ?, DEPT = ? WHERE ( (EMPNO = ?)AND ((ENAME IS NULL AND ?IS NULL) OR (ENAME = ?))AND ((JOB IS NULL AND ?IS NULL) OR (JOB = ?))AND ((MGR IS NULL AND ?IS NULL) OR (MGR = ?))AND ((HIREDATE IS NULL AND ?IS NULL) OR (HIREDATE = ?))AND ((SAL IS NULL AND ?IS NULL) OR (SAL = ?))AND ((COMM IS NULL AND ?IS NULL) OR (COMM = ?))AND ((DEPT IS NULL AND ?IS NULL) OR (DEPT = ?)) )
ほとんどの場合、Command Builder で生成される Update ステートメントや Delete ステートメントよりも、エンド ユーザーの方が効率のよいステートメントを記述できます。
もう 1 つの問題は、CommandBuilder オブジェクトの設計にあります。CommandBuilder オブジェクトは常に DataAdapter オブジェクトと関連付けられ、DataAdapter オブジェクトが生成する RowUpdating イベントと RowUpdated イベントのリスナーとして CommandBuilder オブジェクト自身を登録します。したがって、行を更新するたびに、この 2 つのイベントが処理されなければなりません。
データ型によっては、取得や送信に時間がかかるものがあります。スキーマを設計するときには、最も効率よく処理できるデータ型を選択してください。たとえば、整数データは浮動小数点データより速く処理できます。浮動小数点データは、内部データベース固有の形式に基づいて定義され、通常、圧縮形式になっています。このようなデータは、ワイヤ プロトコルで処理できるように、解凍して別の形式に変換する必要があります。
処理時間が最も短いデータ型は文字列で、その次が整数です。整数の場合は、通常、何らかの変換またはバイトの並べ替えが必要です。浮動小数点データとタイムスタンプの処理には、整数の少なくとも 2 倍の時間が必要です。
|