Original URL: http://www.theregister.co.uk/2010/04/20/verity_stob_sql/

First among SQLs

COBOL for lawyers

By Verity Stob

Posted in Verity Stob, 20th April 2010 11:03 GMT

Stob Legend has it that Edgar 'Ted' Codd got the idea for SQL while attending a 'Sky at Night' spin-off lecture. Patrick Moore, pointing at the blackboard, said: 'Select a star from the table'. 'That's it!', cried Codd, and ran out the door to follow up his inspiration forthwith, missing a good discussion of vulcanoids.

Though born in the '70s, SQL is sentimentally the last of the 1950s languages. While kernighan & pike & ritchie & thompson were going all lower case & curly brackets, the relational pioneers wanted S.Q.L.'s natural temporal home to be with F.O.R.T.R.A.N. and A.L.G.O.L and line printers the size of an Austin Mini. To this day, proper SQL is still mostly written in CAPS - ask any Oracle.

In the same way that COBOL was designed so that businessmen could use it, SQL was similarly imagined so that lawyers could easily pick it up. If you look carefully, you can still detect hints of this legal element in modern SQL code. Its best syntax has that quality of redundant thoroughness that one associates with the small print in licence agreements. A well-drafted SQL statement should look like shouting, but shouting in a nerdy-wordy way. Think John Major defending the Maastricht treaty at the dispatch box:

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

or

GRANT SELECT, INSERT, UPDATE ON suppliers TO my_right_honourable_friend

Nonetheless some of the function names do have a certain kind of strange beauty, which the strstr() vowel-evacuated standard C library rather lacks. For example

COALESCE(ColumnName, ReplacementValue)

sounds like something that happens to null values if they are left out too long in the sun. And so it proves.

The early years of SQL were unhappily mostly taken up with fierce, unproductive disputes regarding which level of normal form was appropriate for practical database design. There was a period when admitting that one only designed one's tables to anything less than the ultra-strict Seventh Normal Form ('values of attributes in a string column not allowed to rhyme, grasshopper') was a social faux pas equivalent to being caught pinching the Pick 'n' Mix in Woolworths.

I will draw a veil over those unhappy times, and also over some of the escapades of the rather excitable denormalisation movement, which famously climaxed in the so-called 'Six O'Clock News incident', with one of their members humiliatingly being sat on by Nicholas Witchell.

SQL, the language

SQL is not without visionary simplifications of the kind that underlie all great programming languages. Whereas lesser parsers report a range of errors in the code fed to them, a strictly standard SQL may only report one:

error near ","

which was cunningly devised to be true-ish under nearly all circumstances.

(Most real-life RDBMSes do not adhere to this rule, but nonetheless stick to the spirit of error concealment. A colleague thoughtlessly named a column Address Id (sic), and in due course received the brusque and baffling warning

JOIN operator not supported

whereas what was actually meant was, of course,

Don't put spaces in column names you dork

He complained bitterly about this, but I cannot agree. Twenty-first century programmers are already ridiculously feather-bedded. Mutter mutter grump.)

Those of you familiar with modern exception-handling will now be wondering if SQL has an EXCEPT keyword. Certainly it does. However, there are two minor problems:

  1. The version of SQL you are using doesn't implement it
  2. It has nothing to do with exceptions.

Devised as part of SQL's cap-doffing to set theory, and of course the late Dr John Venn and his marvellous diagrams, EXCEPT is a sibling operator to the more familiar UNION; the former differing from the latter only in the detail that pretty well nobody knows what it means, and those who do know what it means don't use it.

In fact, great swathes of the SQL standard are unimplemented in actual RDBMSs. SQL standards define features that aren't implemented in the same way that Lieutenant Scheisskopf cancelled non-existent parades in Catch-22. So much lives below the water line of implementation, the language is an ISO iceberg. For example:

This is but a tiny proportion of what your relational database probably doesn't offer you. Cheer up. At least this way you don't waste time thinking of ways to use this stuff.

Trigger is a horse's name

I guess it doesn't matter, because no two implementations of SQL achieve sufficient compatibility with each other that one could run unchanged the simplest demo in the Barry Bear's Big Book of Baby Databases for Tiny Tots (ed J Celko, looking to tone down the elitist stance established by SQL for Smarties). If you want a laugh - albeit a somewhat modest and bitter laugh - just look up the syntax for triggers on Wikipedia. (Here you are.) Depending on which exact flavour of SQL you are driving, the choices will look something like this:

CREATE TRIGGER <TRIGGERNAME>
{BEFORE | AFTER | INSTEAD OF}
{INSERT [OR UPDATE] [OR DELETE] | UPDATE [OR INSERT] [OR DELETE] | DELETE [OR UPDATE] [OR INSERT] }
ON {<TABLENAME>|<VIEWNAME>}
[REFERENCING NEW {ROW | STATEMENT} AS N, OLD {ROW | STATEMENT} AS O]
FOR EACH {ROW | STATEMENT}
[WHEN <BOOLEAN EXPRESSION>]

and we haven't even got to the doings of the trigger yet - this is all preamble. (However it does show something of SQL's preposition obsession. Somebody said once said that there is no problem in programming that cannot be overcome by adding levels of indirection. SQL, I believe, sees it more as a useful evasion tactic, with BEFORE, AFTER, INSTEAD OF, FROM, BY, INTO, AS and their ilk are introduced at every turn as a way of putting off doing something.)

Not that you should be considering using a trigger in a database design. Triggers spring from the automatic constraint-enforcement view of database design, and the lamentable notion that business rules can sensibly be enforced by the RDBMS. Besides, they encourage DBAs, who (as any right-thinking programmer will tell you) have way too much power anyway.

One danger, witnessed by the aforementioned colleague while working with a government database, is that a single action can set off a cascade of triggers. On one occasion, after he had incautiously deleted a row from a certain table, he noticed a rumbling noise, as if of an avalanche, caused by all the disk drives in the building turned on simultaneously, and the lights dimmed alarmingly as cascades of data disappeared into the transaction log's greedy maw.

Another problem can best be demonstrated by a thought experiment. Imagine designing a perfect romance database, in which every doctor must get her nurse, and every nurse his doctor. These constraints are implemented by triggers. Now, whenever you attempt to insert a row into either the nurse or doctor table, you will be blocked by one of the constraints. The whole database has seized as solid as the gears on a £1 coin.

'Aha!', I hear you cry, 'but what if you inserted doctor/nurse pairs as single transactions?'

To which I reply: you may know your SQL, but you know nothing of Lurve. ®