ここにアイデアがあります。エンドユーザーが表示するデータを選択するときではなく、食料雑貨店が新しいオファーを挿入/更新するときに、コストのかかる操作を更新にオフロードできます。これは、並べ替えデータを処理するための非動的な方法のように見えるかもしれませんが、速度が上がる可能性があります。そして、私たちが知っているように、パフォーマンスと他のコーディング要素の間には常にトレードオフがあります。
各オファーと各ソートオプションの次と前を保持するテーブルを作成します。 （または、常に3つの並べ替えオプションがある場合は、これをオファーテーブルに格納できます。クエリ速度がデータベースを非正規化する良い理由です）
したがって、次の列があります：
- 並べ替えの種類（並べ替えなし、価格、クラス、価格の説明）
- オファーID
- 前のID
- 次のID
オファー詳細ページの詳細情報がデータベースから照会されると、NextIDとPrevIDが結果の一部になります。したがって、詳細ページごとに1つのクエリのみが必要になります。
オファーが挿入、更新、または削除されるたびに、sorttypeテーブルの整合性/精度を検証するプロセスを実行する必要があります。