I’ve got a complex SQL where clause that just got more complex because of a requirements change. There are four basic sets of cases, each with a different combination of other factors. It’s more readable (in my opinion) to have the four cases as separate branches of the where clause, and to repeat the redundant criteria in each branch. But I don’t know how well the database engine will optimize that.
Here’s the expression in its redundant form. I’ve replaced the actual criteria with letters. A is the “branching” criterion, which comes in four forms. All of the expressions are in the form field='value', unless otherwise noted.
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
All of the A’s except A4 are in the form field in ('value1','value2'). D is field > 'value'. G is in the form field not in (subquery).
Here’s the expression, factored to (I think) its least redundant form.
B AND C AND D AND (
A1
OR (
E AND F1 AND G AND (
A2
OR (A3 AND A3a)
)
)
OR (A4 AND F2)
My question is whether I should factor this expression into its simplest (least redundant) logical form, or whether it’s OK to keep it in it’s more redundant but also more readable form. The target database is Sybase, but I’d like to know the answer for RDMBSs generally.
In an
RDBMSworld I wouldn’t bother of redundancy much, efficiency is more important here.In your case, I would
UNIONall the four queries usingA‘s as a top condition, like this:I didn’t look into
Sybasefor more than7years, but in all majorRDBMS‘sUNION‘s are more efficient thanOR‘s.See this article in my blog for approach to a silimar problem in
Oracle:UNIONinOracleand also this article for comparison of
UNIONversusORinMySQL:UNIONcompared to one ofORinMySQLI think these approaches will work well for
Sybasetoo.You also need to create indexes on columns used in your conditions to benefit from
UNION‘sUpdate:
Since condition
Gis a subquery, it may probably happen that it needs aHASH JOINto perform fast.HASH JOINrequires a full scan on all unfiltered values, that’s why it may probable be better to filter all values in a single fullscan and then perform aHASH JOIN:To make any further judgements, it will be much better to see the query itself, really.