PHP Web アプリケーションで中央検索機能を設計しています。これは 1 つのテーブルに焦点を当てており、各結果はそのテーブルの 1 つの一意の ID です。残念ながら、この中心的なテーブルに関連するテーブルが数十あり、そのほとんどは 1:n の関係です。さらに残念なことに、私はそれらのかなりの数に参加する必要があります。結果を表示するために必要なデータを収集するためのカップルと、検索基準に従ってフィルタリングするためのカップル。
これを行うには、主に単一のクエリに依存しています。そこには多くの結合があり、ID ごとに表示される結果が 1 つだけであるため、かなり複雑なサブクエリやグループ化にも使用できます。また、ユーザーが設定した並べ替え方法に従って並べ替えられ、LIMIT を使用してページ付けも行われます。
とにかく、このクエリは非常に複雑になりました。私は PHP でうまく構築しましたが、変更またはデバッグするのは PITA です。したがって、私は別のアプローチを検討しており、実際に開発する前に、これがパフォーマンスにとってどれほど悪いか (またはそうでないか) を考えています。考え方は次のとおりです。
検索パラメーターに従ってフィルタリングするだけの、それほど複雑でないクエリを 1 つ実行します。これは、結合が少なくなることを意味し、group by および同様の構造を完全に無視できます。これに対して「SELECT DISTINCT item_id」を実行して、ID のリストを取得します。
次に、別のクエリを実行します。今回は、結果を表示する必要があるテーブルにのみ参加します (現在の合計結合の約 1/4 のみ)。WHERE item_id IN (....) を使用して、"valid " 最初のクエリで収集された ID。
注: 明らかに、IN () には、PHP に依存してコンマ区切りのリストを作成する代わりに、最初のクエリ全体を実際に含めることができます)。
IN のパフォーマンスはどの程度低下しますか? そして、最初のクエリをまったく LIMIT できないことは、どれほど私を傷つけるでしょうか? これがこれに対する一般的なアプローチなのか、それとももっと賢い方法があるのか も疑問に思っています。これに関するご意見に感謝します:)
明確にするための注意: ここでは、いくつかの単純な結合について話しているわけではありません。検索パラメータをアイテム自身のデータだけでなく、その親のデータと比較する必要がある (単純な) 階層データさえあります。私がこれまで取り組んできたプロジェクトで、これほど複雑なクエリに遭遇したことはありません。言うまでもなく、データ自体には固有の複雑さがあり、それがデータ モデルも複雑な理由です。