ページング動作と並び順

FetchXML を使用してデータをクエリする場合、クエリ結果をページングすると、大量の情報を簡単に表示できます。 ページングを使用する場合は、並び順のパラメーターも含めることが重要です。 適切に並び順をつけないと、"次の50" レコードのページング要求は、複数のページにわたって同じレコードを取得する結果となる可能性があり、レビューと編集がはるかに困難になります。 適切なページの並び順には、ページに含まれるレコードを特定するのに役立つ一意の値を含める必要があります。

レガシ ページング

Microsoft Dataverse 内のレガシ ページングは、現在のページまでのクエリのすべての結果をサーバーのメモリに読み込み、ページに必要なレコード数を選択して、残りを無視します。 これには、データをすばやくバック/フォワード ページングする、または特定のページにスキップするなどの利点がありますが、5 万行の制限、大規模で複雑なクエリでのパフォーマンスの問題、任意にソートされた個別のクエリ結果などの制限もあります。

並び順でページングすると、前のページの結果のキャッシュがページング Cookie に保存されます。 これは、データの次のページが何を表示するかを計算するために使用されます。

ユーザーが "order by" パラメーターを指定しない場合、システムは自動的に "order by" <<entity name>>" <<entityId>> asc "を挿入して、いくつかの基本的な並び順を提供します。 クエリされるデータによっては、これは単一のシステムユーザーが任意のクエリ内の複数のレコードに関連付けられる可能性があるため、不適切で予期しない結果になる可能性があります。

個別のクエリが使用されている場合、返されるデータに影響を及ぼす可能性があるため、システムは追加の順序付けを行いません。 FetchXML これらの場合、ページング体験をより一貫させるために、ユーザーは少なくとも 1 つの並び順の値を追加する必要があります。

注意

FetchXML for Dataverse を使用したページングは​​動的です。 レコードが表示されるページは、各ページがレンダリングされるときに決定されます。 1000 レコードが1 ページに 50 表示されている場合、最初の 50 レコードはページ 1 として表示されます。 ページ 2 が要求されると、システムは要求時に次の 50 レコードがどうなるかを決定します。 このため、バック ページングに新しいページング機能を使用することはできません。 レガシ動作はバック ページングに使用され、これはパフォーマンスが低下します。レガシ制限のため、500 ページ以降の戻りは "バックにページング済み" できません。 

並び順が重要な理由

クエリを実行して状態が "オープン" のすべてのレコードを取得すると、1000 が返される可能性があります。 ページ 1 からページ 2 にページングする場合、すべてのレコードの状態が同じであるため、システムがページ 2 に表示する並び順を知る方法はありません。 これらのレコードのページングは効率的でもなく一貫性もありません。

"order by" 値を入力すると、ページング Cookie は追加の値でデータを並べ替え、指定された値に基づいてページの最後のレコードを認識することができます。

例 1

クエリが作成され、'オープン' 状態のすべてのレコードが取得され、すべてのレコードのステータスが含まれ、ページごとに 3 つのレコードが表示されます。 クエリはその後、ステータス順に並べられます。 クエリ結果は、次の表に示すようにページングされます。

完了状態 ステータス ページ
開く アクティブです 1
開く アクティブです 1
開く アクティブです ページ 1 の終わり
開く アクティブです
開く アクティブです
開く 非アクティブ
開く 非アクティブ

ページング Cookie は、ページの最後のレコードに関する情報を保存しますが、この例でページ 2 を取得するときは、一意の識別子がないため、読み込まれた次のページで未表示のレコードが使用されるか、1ページ目にあった最初の 2 つのレコードが含まれていることを確認できます。

この問題を解決するには、クエリに一意の値を持つ "order by" 列を含める必要があります。 複数の "order by" 値を使用することが可能です。 以下は、このクエリのデータを順に並べる良い方法です。

例 2

クエリが作成され、'オープン'、ケース ID などのすべてのステータス状態のすべてのレコードが取得され、ページごとに 3 つのレコードが表示されます。 これはステータスとケース ID (一意の識別子) で並べし、昇順で並びます。 クエリ結果は、以下に示すように結果をページングします。

完了状態 ステータス サポート案件 ID ページ
開く アクティブです Case-0010 1
開く アクティブです Case-0021 1
開く アクティブです Case-0032 ページ 1 の終わり
開く アクティブです Case-0034
開く アクティブです Case-0070
開く 非アクティブ Case-0015
開く 非アクティブ Case-0047

クエリ結果は最初にステータスで並べられ、次にケース ID で昇順で並べられます。 ページ 2 が生成されると、結果は次のようになります。

完了状態 ステータス サポート案件 ID ページ
開く アクティブです Case-0010
開く アクティブです Case-0021
開く アクティブです Case-0032 ページ 1 の終わり
開く アクティブです Case-0034 2
開く アクティブです Case-0070 2
開く 非アクティブ Case-0015
開く 非アクティブ Case-0047

このクエリ セットの 2 ページ目を生成すると、Cookie には Case-0032 が最初のページの最後のレコードとして保存されるため、2 ページ目は、そのレコードの後のセット内の次のレコードで取得されます。 これにより、より一貫した結果が得られます。

並び順の提案

以下は、ページング結果の並び順を改善するためのいくつかの推奨事項と、回避すべきいくつかの領域です。

最良の並び順

  • 一意の識別子を持つ列を常に含めます (つまり、テーブル ID 列、自動番号列、ユーザー/連絡先 ID)

良い並び順

  • 一意の組み合わせになる可能性が最も高い複数のフィールドを含めます。
    • 名 + 姓 + メールアドレス
    • 姓名 + メールアドレス
    • メールアドレス + 会社名

不十分な並び順

  • 一意識別子を含まない並び順

  • 次のような一意性を提供する可能性が低い単一または複数のフィールドを持つ並び順。

    • 状態と進捗状況
    • 選択肢または、はい/いいえ
    • 名前の値自体 (つまり、最後のみ、最初のみ、会社名のみ)
    • タイトル、説明、複数行テキストなどのテキスト フィールド
    • 一意でない数値フィールド

順序付けと複数のテーブル クエリ

複数のテーブルにまたがるデータが必要な場合があり、テーブル JOIN を使用してクエリを実行する必要があります。 このような場合、クエリの両方のテーブルに順序を含めることができます。 ページングが最良の結果を提供することを保証するために、テーブルごとに一意の ID を持つ少なくとも 1 つの列を使用するようにしてください。 ただし、クエリは従来のページングにダウングレードされ、ページング Cookie は返されません。これらの場合、N:1 関係構造の制限によりデータが失われる可能性があります。

関連情報

ページサイズの大きい結果セット FetchXML

注意

ドキュメントの言語設定についてお聞かせください。 簡単な調査を行います。 (この調査は英語です)

この調査には約 7 分かかります。 個人データは収集されません (プライバシー ステートメント)。