SQL PROGRAMMING STYLE- P38 docx

32 CHAPTER 2: FONTS, PUNCTUATION, AND SPACING

3. Put a new line or at least a space after a semicolon to separate
statements.
4. Put a space between words even when you could crowd them
together.

Exceptions:

If SQL does not work the same way as English, then you have to follow
the SQL syntax rules.
Many of the code-formatting habits people have go back to habits
they were taught by programmers who grew up with punchcard data
processing. Because we have video terminals and text editors today, a lot
of habits no longer have any basis.
The practice of putting a comma in front of a single variable on a
single line goes back to punchcards. It was often difficult for
programmers to get to a keypunch machine to create their decks of
cards. In this format, you could pull or insert a card to change your code.
There is no excuse for this practice since we now have video terminals.
English and European languages are read left to right and then top to
bottom. This scanning pattern is so deeply learned that we arrange
schematics, comic books, maps, and other graphics the same way. To see
how much changing that order can throw you off, try to read a Japanese
or Chinese comic book. The panels are in right-to-left order, and the
Chinese word balloons are read top to bottom. This is why typographers
have a rule that you do not set long words
V
E
R

T
T
I
C
A
L
L
Y.
Did you spot the misspelling? About one-third of readers do not.
Likewise, it is difficult to locate duplicates and errors in those long

2.5 Avoid Proprietary Reserved Words if a Standard Keyword Is Available in Your SQL Product 33

vertical lists of names. SQL formatting can use vertical alignment to
advantage in other places but in things that should be chunked together.

2.4 Use Full Reserved Words

Rational:

SQL allows you to skip some reserved words and to abbreviate others.
Try to use the full forms to document the program. This is a good thing
in COBOL, and it works in SQL as well.
For example, an alias can be written with or without an AS operator.
That is, “Personnel AS P1” is equivalent to “Personnel P1” in a FROM
clause, and “(salary + commission) AS total_pay” is equivalent to “(salary
+ commission) total_pay” in a SELECT list. But the AS reserved word
makes it easier to see there is an alias and not a comma in these
situations.
Technically, you can abbreviate INTEGER to INT and DECIMAL to

DEC, but the full names are preferred. The abbreviations look like the
reserved word “into” or the month “Dec” in English.

Exceptions:

The exception is to use the shorter forms of the character data types.
That is, CHAR(n) instead of CHARACTER(n), VARCHAR(n) instead of
VARYING CHARACTER(n), NCHAR(n) instead of NATIONAL
CHARACTER(n), and NVARCHAR(n) instead of NATIONAL VARYING
CHARACTER(n). The full names are too long to be comfortable to a
reader. Even COBOL, the most verbose programming language on earth,
allows some abbreviations.

2.5 Avoid Proprietary Reserved Words if a Standard
Keyword Is Available in Your SQL Product

Rationale:

Sticking to standards will make your code readable to other SQL
programmers who might not know your dialect. It also means that your
code can run on other products without being rewritten.
Standard code will protect you from failure when the proprietary
syntax is dropped or modified. That unwelcome surprise occurred in
several products when the vendors added the Standard SQL versions of
OUTER JOINs and deprecated



their old proprietary versions. In
particular, SQL Server programmers had to unlearn their *= syntax and

semantics for outer joins.

34 CHAPTER 2: FONTS, PUNCTUATION, AND SPACING

The other disadvantage of proprietary features is that they change
over time and have no standard behavior. For example, the BIT data
type in SQL Server changed its NULL-ability between product releases.
Oracle could not tell an empty string from a NULL. There are lots of
other examples. Because there is no external standard to appeal, a
vendor is free to do anything it wishes.

Exceptions:

If your SQL product does not yet support standard syntax for something,
then you have no choice. This is true for temporal functions. They were
late getting to Standard SQL, so the early vendors made up their own
syntax and internal temporal models.

2.6 Avoid Proprietary Statements if a Standard Statement
Is Available

Rationale:

This rule ought to be obvious. Sticking to standards will make your code
readable to other SQL programmers who might not know your dialect. It
also means that your code can run on other products without being
rewritten. Standard code will protect your code from failure when the
proprietary syntax is dropped or modified.
In fact, a vendor can actually give you proprietary features that are
unpredictable! In the “Books On Line” interactive manual that comes

with Microsoft SQL Server, we get a warning in the REMARKS section
about the proprietary “UPDATE FROM ” syntax that tells us:
The results of an UPDATE statement are undefined if the state-
ment includes a FROM clause that is not specified in such a
way that only one value is available for each column occur-
rence that is updated (in other words, if the UPDATE statement
is not deterministic). For example, given the UPDATE state-
ment in the following script, both rows in table S meet the
qualifications of the FROM clause in the UPDATE statement,
but it is undefined which row from S is used to update the row
in table T.
This replaces a prior behavior found in the Sybase and Ingres family
where the UPDATE FROM would do multiple updates, one for each
joined row in the second table.

2.6 Avoid Proprietary Statements if a Standard Statement Is Available 35

In older versions of Sybase/SQL Server, if a base table row is
represented more than once in the embedded query, then that row is
operated on multiple times instead of just once. This is a total violation
of relational principles, but it’s easy to do with the underlying physical
implementation. Here is a quick example:

CREATE TABLE T1 (x INTEGER NOT NULL);
INSERT INTO T1 VALUES (1);
INSERT INTO T1 VALUES (2);
INSERT INTO T1 VALUES (3);
INSERT INTO T1 VALUES (4);
CREATE TABLE T2 (x INTEGER NOT NULL);
INSERT INTO T2 VALUES (1);

INSERT INTO T2 VALUES (1);
INSERT INTO T2 VALUES (1);
INSERT INTO T2 VALUES (1);

Now try to update T1 by doubling all the rows that have a match in T2.

UPDATE T1
SET T1.x = 2 * T1.x
FROM T2
WHERE T1.x = T2.x;
SELECT * FROM T1;
original current
x x
==== ====
16 2
2 2
3 3
4 4

The FROM clause gives you a CROSS JOIN, so you get a series of four
actions on the same row (1 => 2 => 4 => 8 => 16). These are pretty
simple examples, but you get the idea. There are subtle things with self-
joins and the diseased mutant T-SQL syntax that can hang you in loops

36 CHAPTER 2: FONTS, PUNCTUATION, AND SPACING

by changing things, or you can have tables that depend on the order of
the rows for their results, and so forth.
SQL Server and Sybase used different fixes for this problem in later
versions of their products. Sybase did a hidden “SELECT DISTINCT” in

the implied query, and SQL Server gets an unpredictable row. Standard
SQL is consistent and clear about aliases, views, and derived tables, as
well as a highly orthogonal language.
If the UPDATE clause could take an alias, according to the Standard
SQL model, then you would create a copy of the contents of that base
table under the alias name, then update that copy, and delete it when the
statement was over—in effect doing nothing to the base table.
If the UPDATE clause could take a FROM clause, according to the
Standard SQL model, then you would create a result set from the table
expression, then update that copy, and delete it when the statement was
over—in effect doing nothing to the base tables.
Because this syntax is so proprietary, inconsistent with the standard
model, and ambiguous, why does it exist? In the original Sybase
product, the physical model made this “extension” relatively easy to
implement, and there were no standards or a good understanding of the
relational model back then. Programmers got used to it and then it was
almost impossible to fix.
When I lived in Indianapolis in the mid-1970s, my neighbor had
graduated from General Motors private college and gone to work for the
company. His first job was investigating industrial accident reports. We
were having a beer one night, and he got to telling war stories from the
various General Motors plants he had been to for his job. His conclusion
after a year on that job was that all industrial accidents are bizarre suicide
attempts. People would go to the machine shop and build clever devices
to short around the safety features on their equipment so they could
work a little faster.
For example, if you make a clamp that holds in one of the two safety
switches that operates a small stamping machine, you can push the other
button with one hand and work material with your free hand. Well, you
can do this until that free hand is crushed just above the wrist and

squirts across the back wall of the shop anyway. Trading speed for safety
and correctness will eventually catch up with you.

Exceptions:

If your SQL product does not yet support standard syntax for something,
then you have no choice. For example, Oracle did not support the CASE