最適化されたクエリ データ パターン
最も単純かつ最速のデータ クエリ パターンは次のとおりです。
- 単一テーブルまたはビュー
- サーバー上で必要なものを事前にフィルタリング
- 列には、予期されるクエリに対して正しくインデックスを付けられる
アプリを設計するときは、データを迅速にクエリする方法を考える必要があります。 データをクエリする最善の方法は、必要な情報をすべて含む単一のテーブルまたはビューを使用し、アプリで表示する前にサーバー上でフィルター処理することです。 データのフィルターまたは並べ替えに使用する列に適切にインデックスが付けられていることを確認する必要もあります。 これにより、アプリがより高速かつスムーズになります。
たとえば、顧客とその営業担当者のリストを表示するギャラリーがあるとします。 顧客と営業担当者の情報を別のテーブルに保存する場合は、ルックアップを使用して各顧客の営業担当者名を取得する必要があります。 これにより、他のテーブルに対して多くのクエリを実行する必要があるため、アプリの速度が低下します。 良い方法は、顧客と営業担当者の情報を 1 つのテーブルに結合したビューを作成し、そのビューをギャラリーのデータ ソースとして使用することです。 そうすれば、アプリは 1 つのクエリを実行するだけで、必要なデータをすべて取得できます。
クエリ速度とデータ正規化の間にはトレードオフがあります。 データ正規化とは、データを 1 回だけ保存し、重複を避けることを意味します。 これは、データの一貫性と正確性を維持するのに役立ちます。 ただし、クエリをより速く簡単に行うために、一部のデータを複製する必要がある場合があります。 アプリの設計とテーブル構造では、これら 2 つの目標のバランスを取る必要があります。 そうしないと、さまざまなテーブルのデータをフィルターして結合するために多数の作業を行う必要があるため、アプリが遅くなり、遅れが生じます。
サーバー側ビューを使用する
ビューはおそらく、これらの目標のバランスを取るのに役立つ最も一般的なツールです。 これらは、クエリに対して単一のテーブル構造を提示し、クエリで必要なデータを事前にフィルタリングし、ルックアップと他のテーブルへの結合を可能にします。 ビューのフィルター、検索、結合はサーバー上で計算されるため、ペイロードとクライアント側の計算の両方が最小限に抑えられます。
ギャラリーを検索しすぎないようにする
ギャラリーには、データ ソースからの多くのレコードを表示できます。 ただし、元のデータ ソースに関連する別のデータ ソースからの追加情報を表示する必要がある場合があります。 たとえば、顧客のリストを表示するギャラリーがあり、各顧客に割り当てられた営業担当者の名前を表示したいとします。 営業担当者の名前は、顧客の情報とは別のデータ ソースに保存されます。 営業担当者の名前を表示するには、他のデータ ソースで一致するレコードを見つける検索関数を使用する必要があります。 これにより、元のテーブルがルックアップ値で拡張されます。
ただし、多数のレコードと多数の検索がある場合、テーブルの拡張は非常に遅くなる可能性があります。 ギャラリー内のレコードごとに、アプリは他のデータ ソースに対して個別のクエリを実行し、ルックアップ値を取得する必要があります。 これは、アプリがレコードごとに多くのクエリを実行する必要がある可能性があり、時間がかかり、アプリのパフォーマンスに影響を与える可能性があることを意味します。 このアンチパターンは、「Nの2乗 (n^2)」または「N+1」問題として知られることがあります。
StartsWith または Filter の使用
Power Fx はデータを検索するいくつかの方法を提供します。 一般に、次のようなインデックスを利用する式を使用します。in のようにテーブル全体を読み取るものではなく、StartsWith または Filter のようなインデックスを利用する式を使用します。 In 演算子は、メモリ内のコレクション、または外部データ ソース テーブルが非常に小さい場合に適しています。
データの複製を検討する
データが別の場所または形式で保存されているために、クエリでのアクセスが遅くなる場合があります。 クエリを高速化するには、遅いデータをコピーし、クエリが高速で簡単なテーブルにローカルに保存します。 ただし、これは、ローカル データが元のデータの最新バージョンではない可能性があることを意味します。 次に、別のプロセスを実行してローカル データを定期的に更新します。 このプロセスは、Power Automate フロー、プラグイン、ストアド プロシージャ、またはデータをある場所から別の場所に移動できるその他のメソッドのいずれかにすることができます。
ローカル データを更新する頻度の要件は、ビジネス ニーズによって異なります。 アプリのデータはどの程度新鮮である必要がありますか? たとえば、自転車を販売する会社 Contoso で働いているとします。 利用可能な自転車のリストは、カスタム コネクタの API を介してアクセスできる製品データベースに保存されます。 しかし、API 呼び出しが遅いため、商品データをコピーしてローカルのテーブルに保存することにしたとします。 次に、テーブルとアプリの他の関連データを結合するビューを作成します。 また、API からの最新の製品データでテーブルを毎日実行し、更新する Power Automate フローも作成します。 そうすれば、アプリはローカル データをより速くクエリできるようになり、データの古いものは長くても 1 日だけになります。
データの複製は、エンタープライズ グレードのアプリケーションで良好なパフォーマンスを確保するための一般的な手法です。 Dataverse プラグイン、ストアド プロシージャ、またはデータ移動を使用して、クエリ用に最適化された単一のテーブルにデータを複製できます。 重要な質問は、このデータはどの程度最新のものである必要があるかということです。 多少の遅延が許容できる場合は、このテクニックを使用してアプリを高速化できます。
サジェスチョン
この目標を達成するには、次の質問と提案を考慮してください。
- 顧客にとって、ギャラリーまたはデータ グリッドでデータ値を確認することはどの程度重要ですか? 最初にレコードを選択してから、フォームにデータを表示することは許容されますか?
- データを正しい形式で表示するために必要な事前作業をビューで実行できますか?
- 「StartsWith」が機能する「IN」演算子を使用していますか?
- データはどの程度最新である必要がありますか? 既定で単一のテーブルに対してクエリを実行するために使用できるデータ複製戦略はありますか?