ODataを使用して行を並べ替える
アイテムが返される順序を指定するには、 $orderby クエリ オプション を使用します。 asc または desc 接尾辞を使用して、それぞれ昇順または降順を指定します。 既定は昇順です。 以下の例では、アカウントの name プロパティと revenue プロパティを、revenue を昇順で、name を降順で取得します。
GET [Organization URI]/api/data/v9.2/accounts?$select=name,revenue
&$orderby=revenue asc,name desc
&$filter=revenue ne null
ルックアップ列と選択列の順序付け
ほとんどの列タイプに含まれるデータは比較的単純なので、意味のある並べ替え操作を実行できます。 データベースに保存されているデータはコンテキストを離れては意味を持たないため、ルックアップ列と選択列はより複雑になります。
検索列
ルックアップ列を使用して並べ替えると、結果は関連テーブルのプライマリ名フィールドを使用して並べ替えられます。 データベースには GUID 値が格納されます。 返される フォーマットされた値 は、対応する主な名前フィールドです。
列の選択
選択列を使用して並べ替えると、結果は選択の整数値を使用して並べ替えられます。
注意
これは、 FetchXml または QueryExpressionを使用して選択値を並べ替える方法とは異なります。 このような場合、結果は選択肢のローカライズされたラベルによって並べ替えられます。
Dataverse Web APIを使用して選択肢ラベルで結果を並べ替えるには、FetchXmlを使用してクエリを作成する必要があります。
ページングと並び順
ページの順序は、データをページングする際に大きな違いをもたらします。 結果の順序に関する情報があいまいな場合、Dataverse はページングされたデータを一貫して効率的に返すことができません。
クエリの順序を指定します。 FetchXml では、クエリに順序要素を追加しない場合、Dataverse がテーブルの主キーに基づいて順序を追加します。 ただし、QueryExpression の場合は異なり、クエリで distinct 結果を指定すると、主キー値が返されないため、Dataverse はこの既定の順序を追加することはできません。 ページングの順序を指定してください。 順序を指定しないと、distinct クエリの結果がランダムな順序で返される可能性があります。 OData では個別の結果を返すオプションは提供されていませんが、ページ化された結果を取得するときには順序を適用する必要があります。
ページングは動的です。 各リクエストは受信時に独立して評価されます。 ページング Cookie は Dataverse に前のページを伝えます。 このページング Cookie データを使用すると、Dataverse は前のページの最後のレコードの次のレコードから開始できます。
ページングは今後も最適に機能します。 以前に取得したページに戻って取得すると、最後にページを取得してからの間にレコードが追加、削除、または変更されている可能性があるため、結果が異なる可能性があります。 つまり、ページ サイズが 50 で前に戻ると、50 レコードが取得されますが、それらは同じ 50 レコードではない可能性があります。 データ セットのページを進め続けると、すべてのレコードが一貫した順序で返されることが期待できます。
決定論的な順序付けが重要となります
決定的順序付け とは、順序を一貫して計算する方法があることを意味します。 指定されたレコードのセットでは、レコードは常に同じ順序で返されます。 一貫した順序とページングが必要な場合は、一意の値または列値の組み合わせをいくつか含め、それらが評価される順序を指定する必要があります。
非決定的な例
ここで nondeterministic のサンプルを見てみましょう。 このデータセットには 状態 と ステータス の情報のみが含まれ、オープン 状態 のレコードのみを返すようにフィルターされています。 結果は、ステータス によって次のように並べ替えられます。 最初の 3 ページが要求されます。 結果はこのようになります:
| 状態 | Status | ぺージ |
|---|---|---|
| 始 | アクティブです | 1 スタート |
| 始 | アクティブです | 1 |
| 始 | アクティブです | 1 終了 |
| 始 | アクティブです | |
| 始 | アクティブです | |
| 始 | 非アクティブ | |
| 始 | 非アクティブ |
ページング Cookie は、ページ上の最後のレコードに関する情報を保存します。 次のページが要求された場合、最初のページの最後のレコードは含まれません。 ただし、非決定的なデータを考えると、最初のページの他の 2 つのレコードが 2 番目のページに含まれていないという保証はありません。
決定的な順序付けを実現するには、一意の値または半一意の値を含む列に順序を追加します。
決定的な例
このクエリは非決定的なクエリと似ていますが、一意な値を含むケース ID 列を含んでいます。 ステータス順でもありますが、ケース ID の使用用途順でもあります。 結果はこのようになります:
| 状態 | Status | サポート案件 ID | ぺージ |
|---|---|---|---|
| 始 | アクティブです | Case-0010 | 1 スタート |
| 始 | アクティブです | Case-0021 | 1 |
| 始 | アクティブです | Case-0032 | 1 終了 |
| 始 | アクティブです | Case-0034 | |
| 始 | アクティブです | Case-0070 | |
| 始 | 非アクティブ | Case-0015 | |
| 始 | 非アクティブ | Case-0047 |
次のページでは、cookie は最初のページの最後のレコードとして Case-0032 を保存しているので、2 ページ目はそのレコードの次のレコードから始まります。 結果はこのようになります:
| 状態 | Status | サポート案件 ID | ぺージ |
|---|---|---|---|
| 始 | アクティブです | Case-0010 | 1 スタート |
| 始 | アクティブです | Case-0021 | 1 |
| 始 | アクティブです | Case-0032 | 1 終了 |
| 始 | アクティブです | Case-0034 | 2 スタート |
| 始 | アクティブです | Case-0070 | 2 |
| 始 | 非アクティブ | Case-0015 | 2 終了 |
| 始 | 非アクティブ | Case-0047 |
このクエリは一意の列値を順序付けするため、順序は一貫しています。
データをページングするときの注文のベスト プラクティス
注意
可能な場合、クエリはテーブルの主キーに基づいて順序付けされる必要があります。 Dataverse は、既定で主キーの順序付けに最適化されています。 一意でないフィールドまたは複雑なフィールドで順序付けすると、過剰なオーバーヘッドが発生し、クエリが遅くなります。
アプリケーションで表示するために限られたデータセットを取得する場合、または 5,000 行以上のデータを返す必要がある場合は、結果をページングする必要があります。 結果の順序を決定する際の選択によって、取得するデータの各ページの行が他のページと重なるかどうかが決まります。 適切に順序付けしない場合、同じレコードが複数のページに表示される可能性があります。
同じレコードが複数のページに表示されないようにするには、次のベスト プラクティスを適用します:
一意の識別子を持つ列を含めることをお勧めします。 例:
- テーブルの主キー列
- オートナンバー列
- ユーザー/連絡先 ID
一意の識別子を持つ列を含めることができない場合は、一意の組み合わせになる可能性が最も高い複数のフィールドを含めます。 例:
- 名 + 姓 + メールアドレス
- 姓名 + メールアドレス
- メールアドレス + 会社名
データをページングする際の注文のアンチパターン
避けるべき順序の選択肢は次のとおりです:
一意識別子を含まない並び順
計算フィールドの注文
次のような一意性を提供する可能性が低い単一または複数のフィールドを持つ並び順:
- 状態と進捗状況
- 選択肢または、はい/いいえ
- 値自体に名前を付けます。 例:
name、firstname、lastname。 - タイトル、説明、複数行テキストなどのテキスト フィールド
- 一意でない数値フィールド
次の手順
行をフィルター処理する方法について説明します。
注意
ドキュメントの言語設定についてお聞かせください。 簡単な調査を行います。 (この調査は英語です)
この調査には約 7 分かかります。 個人データは収集されません (プライバシー ステートメント)。