複雑なSQL where節があります。ケースには4つの基本的なケースがあり、それぞれに異なる要因の組み合わせがあります。 4つのケースをwhere句の別々のブランチとして持ち、各ブランチで重複した基準を繰り返すことは、わかりやすい(私の意見では)。しかし、データベースエンジンがそれをどれだけうまく最適化するかはわかりません。複雑なSQL where節:因数論理にするかどうか
ここでは、その冗長形式の表現です。私は実際の基準を手紙で置き換えました。 Aは4つの形式で提供される「分岐」基準です。特に明記しない限り、すべての式はfield='value'
の形式になっています。
A1 AND B AND C AND D
OR A2 AND B AND C AND D AND E AND F1 AND G
OR A3 AND A3a AND B AND C AND D AND E AND F1 AND G
OR A4 AND B AND C AND D AND F2
AのA4を除くすべてが形field in ('value1','value2')
です。 Dはfield > 'value'
です。 Gはfield not in (subquery)
の形式です。
ここでは、最小限の冗長形式を考慮して表現しています。
B AND C AND D AND (
A1
OR (
E AND F1 AND G AND (
A2
OR (A3 AND A3a)
)
)
OR (A4 AND F2)
私の質問は、私は最も簡単な(少なくとも冗長)論理フォーム、または、それがより多くの冗長なだけでなく、より読みやすい形式だでそれを維持するためにOKだかどうかにこの式を考慮する必要があるかどうかです。ターゲットデータベースはSybaseですが、一般的なRDMBSの答えを知りたいと思います。
良い提案です。基準Gがサブクエリを使用するという事実は、UNIONアプローチの効率性が低下するか(理論的には2つのSELECTで発生するため)、データベースエンジンはこれらのタイプのものを最適化しますか? –
Gについては、クエリ自体を見て判断する必要があります。サブクエリが複雑な場合、Gはおそらく、UNIONで区切られた別のクエリで使用されるインデックスのすべてのメリットを殺す可能性があります。たぶん完全なテーブルスキャンが良いでしょう。 – Quassnoi
サブクエリロジックはシンプルですが、テーブルが巨大です。サブクエリはインデックス付きフィールドで選択しているので、それほど悪くないかもしれません。私は、この特定のケースは、私はいくつかの異なる方法を試して、何が最もうまくいくかを見なければならないものだと思います。 –