SQL PROGRAMMING STYLE- P21 docx

6.2 Pick Compact Constructions over Longer Equivalents 117 which is a little cleaner than: WHERE (a IN (x, y) OR z IS NULL) 6.2.4.3 Use CASE Expressions, Not Complex Nested Predicates An advanced trick in the WHERE clause is to use a CASE expression for a complex predicate with material implications. If you forgot your freshman logic, a material implication logical operator is written as an arrow with two tails, and it means “p implies q” or “if p is true then q is true” in English. WHERE CASE WHEN <search condition #1> THEN 1 WHEN <search condition #2> THEN 1 ELSE 0 END = 1 The use of a function that returns one or zero when given a predicate as its parameter is called a characteristic function in logic and set theory. Review the rules for the CASE expression in section 6.2.2 first, so you understand it. The order of execution of the WHEN clauses can be used to optimize performance and avoid redundant tests. You can also nest CASE expressions inside the WHEN and THEN clauses of a containing CASE expression and display the logic as an indented tree structure. WHERE CASE WHEN <search condition #1> THEN CASE WHEN <search condition #1.1> THEN 1 WHEN <search condition #1.2> THEN 1 ELSE 0 END WHEN <search condition #2> THEN 1 ELSE 0 END = 1 The goal of this technique is to replace pages of long lists of simple theta expressions inside horrible levels of parentheses and to provide 118 CHAPTER 6: CODING CHOICES some short-circuit evaluation as a bonus. When the nesting is too messy to understand, stop and reconsider your logic. Decision table tools, such as Logic Gem, are an excellent way to do this. 6.3 Use Comments Rationale: The best documentation for maintaining a program has been comments in the code. Perhaps it is easier for procedural language programmers to add comments because they are explaining in a narrative fashion what their program is doing. Unfortunately, procedural language comments are often redundant if you can read the code. How much help did you get from: UPDATE Teams SET score = score + 1;—increment score which gives you no information about what the variable score means and why it is incremented. In Standard SQL, a comment begins with two dashes ( ) and ends with a new line, because the first SQL engines were on IBM mainframes and used punchcards. This format is a poor choice with modern computers that can store free-form text. Word wrap in program text can split a comment and give you errors. Because SQL supports the unary minus operator, this is ambiguous in some rare situations and makes the compiler work extra hard. Later standards added the C style /* and */ pairs, and many vendors have similar comment brackets. They are a better choice. SQL programmers do not like to put comments in their code, not even redundant or useless ones. My guess is that because SQL does a lot of work in one statement and programmers have been taught to comment the code at the statement execution level rather than explain the purpose of the code, the higher level of abstraction confuses them. They are not inclined to put comments at the clause level because the appearance of the code can be crowded. Get over it. You need a high-level descriptive comment on a block of SQL, and then more detailed comments on a few important clauses. Try to keep the comments aimed at non-SQL programmers and in plain English. For example, don’t say “relational division of motor pool vehicles by available drivers” on the assumption that the reader will 6.3 Use Comments 119 know what a relational division is. Try “list all drivers who can drive all the vehicles in the motor pool” instead. The other trick is to reference the documentation for the schema and the applications. This assumes that they are current and useful, however. If you have the time, another guru-level trick is to save the best of the various statements you tried that worked but did not perform as well as the final choice as comments. In SQL, what was the best answer in one situation is often no longer the best answer. Instead of making the next programmer start from scratch, share your notes. Exceptions: In a well-designed schema with good data element names, much of the code is easy for an experienced SQL programmer to read. You can skip comments on single statements if their intent is really obvious, but remember that one programmer’s obvious is another’s “what the heck?” when you code. 6.3.1 Stored Procedures Always start a stored procedure with a comment that gives at least the author, the date, and the update history. This is simply basic software management. After that, add a high-level description of the function of this module. The procedure name will be in a “<verb><object>” format. Each parameter should have a comment as needed. 6.3.2 Control Statement Comments Comments on control statements, such as IF-THEN-ELSE, BEGIN-END, and WHILE-DO loops, will look much like comments in any procedural program. Complicated SQL statements need a comment at the top and often comments at the clause level. 6.3.3 Comments on Clause This point is difficult to generalize, but things that act as a unit might need a comment. For example, a derived table for which there is no good alias might need a comment to explain what it contains. A series of predicates that define a complicated join might be prefaced with a comment to explain what they are doing at a higher level. 120 CHAPTER 6: CODING CHOICES 6.4 Avoid Optimizer Hints Rationale: Many products have proprietary syntax for sending parameters to the optimizer to change the execution plan for a statement. Because each physical implementation is different, this syntax will not be portable, but there are other problems too. First, the optimizer is usually smarter than the programmer and finds a good plan. People cannot handle computations that involve tens of parameters very well. Second, once a hint is put on a statement, it stays there permanently, long after the reason for the hint is gone. A typical example of this would set up a query hint for a skewed statistical distribution and then, as the database grows, the distribution becomes more normal or skewed in the opposite direction. The hint that used to be so helpful is now a handicap. Exceptions: If you do have a skewed statistical distribution or other weirdness in your data that is destroying performance, then use a hint. Set up a review of all statements with hints to see if they actually need to be maintained. Reviews should occur when a new release of database is installed (optimizer might be better) or the statistics of one or more of the tables change (data might be better), but if the performance is acceptable, then do not use hints. 6.5 Avoid Triggers in Favor of DRI Actions Rationale: Although there is an ANSI/ISO standard for triggers, their syntax and semantics are still highly proprietary. Triggers are blocks of procedural code that are executed (fired) when a database event occurs to a table. This code is usually in a proprietary 3GL language. A database event is something that changes the data—an insert, update, or delete. The full ANSI version of triggers does not fire on an insertion, but some vendor products do. The full ANSI version of triggers have more than one trigger on a table and can fire them in a sequence either before or after the database event. Most vendor products do not have that much control over the triggers. On the other hand, the syntax and semantics for DRI actions are well defined and standardized. A newbie posted a topic under the title “Need Help with a Calculation Trigger” on the forums in the SQL Server Central Web site in November 2004. This person was having trouble setting up a trigger to check the 6.5 Avoid Triggers in Favor of DRI Actions 121 units of a “number field [sic]”; the real problem was that the poster did not know that a column is not a field. For some reason, the column was declared as FLOAT and was called length. The trouble is that some people were entering a length in meters, centimeters, and millimeters. The poster was trying to code a trigger that will fire on UPDATE or INSERT to check the value of length. If it is greater than 20, chances are the number is in millimeters and should be divided by 10. If the number is less than 0, then the number is probably in meters and should be multiplied by 100. CREATE TRIGGER SetCentimeters AFTER INSERT ON Samples UPDATE Samples SET length = (CASE WHEN length > 10.00 THEN Length / 10.00 WHEN length < 0.00 THEN Length * 100.00 ELSE Length END) WHERE length NOT BETWEEN 0.00 AND 10.00; However, this is the wrong answer. It is in procedural code. The right answer is in the DDL, with something like this: length DECIMAL(2,1) NOT NULL CONSTRAINT length_in_centimeters_only CHECK (length BETWEEN 0.01 AND 9.99) Triggers tend to fix errors on the fly; the goal is not to permit them in the first place. Exceptions: Some things should be done with triggers because you cannot do them with DRI. In particular, the INSTEAD OF trigger has to be used for updatable views. This trigger is attached to a VIEW, and instead of taking actions on the VIEW, it changes the base tables from which the VIEW is built, so that the user sees those changes reflected in the VIEW. Heuristics tend to favor stored procedures over triggers. A trigger fires every time its database event occurs, which puts it out of your control and adds that overhead to each database event. A stored . score means and why it is incremented. In Standard SQL, a comment begins with two dashes ( ) and ends with a new line, because the first SQL engines were on IBM mainframes and used punchcards brackets. They are a better choice. SQL programmers do not like to put comments in their code, not even redundant or useless ones. My guess is that because SQL does a lot of work in one statement. high-level descriptive comment on a block of SQL, and then more detailed comments on a few important clauses. Try to keep the comments aimed at non -SQL programmers and in plain English. For example,