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