General rules for simplifying SQL statements

Question

I\'m looking for some \"inference rules\" (similar to set operation rules or logic rules) which I can use to reduce a SQL query in complexity or size. Does there exist some

Answer 1

Although simplification may not equal optimization, simplification can be important in writing readable SQL code, which is in turn critical to being able to check your SQL code for conceptual correctness (not syntactic correctness, which your development environment should check for you). It seems to me that in an ideal world, we would write the most simple, readable SQL code and then the optimizer would rewrite that SQL code to be in whatever form (perhaps more verbose) would run the fastest.

I have found that thinking of SQL statements as based on set logic is very useful, particularly if I need to combine where clauses or figure out a complex negation of a where clause. I use the laws of boolean algebra in this case.

The most important ones for simplifying a where clause are probably DeMorgan's Laws (note that "·" is "AND" and "+" is "OR"):

• NOT (x · y) = NOT x + NOT y
• NOT (x + y) = NOT x · NOT y

This translates in SQL to:

NOT (expr1 AND expr2) -> NOT expr1 OR NOT expr2
NOT (expr1 OR expr2) -> NOT expr1 AND NOT expr2

These laws can be very useful in simplifying where clauses with lots of nested AND and OR parts.

It is also useful to remember that the statement field1 IN (value1, value2, ...) is equivalent to field1 = value1 OR field1 = value2 OR ... . This allows you to negate the IN () one of two ways:

NOT field1 IN (value1, value2)  -- for longer lists
NOT field1 = value1 AND NOT field1 = value2  -- for shorter lists

A sub-query can be thought of this way also. For example, this negated where clause:

NOT (table1.field1 = value1 AND EXISTS (SELECT * FROM table2 WHERE table1.field1 = table2.field2))

can be rewritten as:

NOT table1.field1 = value1 OR NOT EXISTS (SELECT * FROM table2 WHERE table1.field1 = table2.field2))

These laws do not tell you how to transform a SQL query using a subquery into one using a join, but boolean logic can help you understand join types and what your query should be returning. For example, with tables A and B, an INNER JOIN is like A AND B, a LEFT OUTER JOIN is like (A AND NOT B) OR (A AND B) which simplifies to A OR (A AND B), and a FULL OUTER JOIN is A OR (A AND B) OR B which simplifies to A OR B.

Answer 2

I like everyone on a team to follow a set of standards to make code readable, maintainable, understandable, washable, etc.. :)

• everyone uses the same alias
• no cursors. no loops
• why even think of IN when you can EXISTS
• INDENT
• Consistency in coding style

there is some more stuff here What are some of your most useful database standards?