Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

When the next object-persistence boat comes in.

I was reading a MCP training manual for SQL Server the other day. It was good. The whole of TSQL was covered in four hundred pages. It didn’t go into anything esoteric, mind you, but it explained such things as remote transactions and locking hints with precision and clarity. There was even room for questions and summaries. Once you’ve put the book down, you’re ready to get to work.

OK. One detail I didn’t mention. This was SQL Server 6.5. However, the coverage was still impressive. With one or two exceptions, the features they describe are all still there. It got me thinking. I regularly have to plough through 800-1000 page books that just try to explain SSIS or SSAS, let alone the 800-1000 page page books on SQL Server Database Engine. Without exception, they try for comprehensive coverage, and dive into every black hole of technical knowledge that will leave anyone who is new to SQL feeling inadequate, and resentful. There is a strange compulsion to explain the intimate details of parts of the database engine that should by rights remain under the metaphorical underwear. The brief book that keeps to the point is going out of fashion.

What has gone wrong? It is not just that Technical writers seem to have slipped the leash and are bounding about, beyond the control of their editors. You can just blame them because SQL itself has doubled in complexity.

SQL was devised to be a simple language that anyone who wanted to could pick up enough knowledge to get reports from data. It was a determined and courageous move. The problem is that, to do anything simple in IT, one is engaged in a constant battle against the IT-Crazies who adore complexity, and like nothing better than wrapping a cocoon of runic mystery around their work. The insertion of XML seemed sensible at the time. It didn’t seem like a big thing. In fact, it forced Microsoft’s hand to sort out the large data types. However, the addition of such things as XQuery, XPath, XSD, FOR XML and OpenXML have bulked up the required reading for a database developer more than somewhat.

The trouble with redesigning a language in order to accommodate a particular programming culture is that there is no obvious stopping place once you have started down this road. What about YAML support to help the Ruby-users? Why no ‘FOR JSON’, or JSON shredders for the AJAX bods? Once one has allowed a completely different declarative language for XML, why not give the same privilege to other object-persistence devices? XML isn’t likely to be the be-all –and-end-all . It is one of those CSV-on-steroids ways of describing data which promises more than it delivers. As soon as one points out a flaw, it gets fixed. It is like a leaky boat where the leaks are getting plugged as fast as they’re found. It remains a leaky boat, though. A new convention will be found for representing object data. Maybe YAML is the next tub to hove into view. You can be sure that it will bulk up the SQL Server manuals again when the next big object-persistence thing hits shore.


Comments

Posted by Foreseer on 29 June 2009

Maybe, Microsoft can go this way - http://www.eloquera.com

This is the .NET-based object database with SQL support. It natively stores .NET objects, and allows retrieving them using SQL with array and complex object support. Who knows may this will be the next big thing?

Posted by Darren Wallace on 29 June 2009

>>With one or two exceptions, the features they describe are all still there.

I think you've found the reason there are no new books that just cover what was written in the SQL Server 6.5 book, it was already covered in the old book and hasn't changed substantially. Nobody wants to be responsable for rewriting a book that was written 10 years ago when there are only (relatively) minor changes to the material.

A lot of the changes to the database engine for SQL Server have been in the dark arcane depths. SSIS, SSRS, SSMS, SS*S have all really been add on products that, at least theoretically, stand alone. You can find a million books that explain SSRS or SSIS in broad, sometimes even usaful, terms in every book store.

As for the potential inclusion of "FOR BADGER" to support the next shiny new tech... meh. They'll add it. We'll ignore it. The curmudgeonly amongst the community will shake a fist and insist it be kept off of the lawn. The ever enthusiastic will proclaim the great usefullness of small mammals and wonder how anyone ever wrote anything without full integrated support. Life will continue as before and I'll get to exercise my fist shaking.

Posted by Bruce W Cassidy on 29 June 2009

One of the simplest programming languages I ever had the chance to play with was called Oberon.  It was the brain child of Niclaus Wirth, and was specifically designed to hit the "all you need in a programming language and nothing extra" target.

Then along came Oberon 2.  *sigh*

I don't think the additional complexity of SQL is entirely at Microsoft's door.  Some of the stuff I find hardest to wrap my head around are the windowed aggregates, which are so far as I know, part of the SQL standard.

But in general, it does feel sad that languages have to grow in complexity.  On the other hand, it's just an expression of reality.  Can you imagine the furor if Microsoft were to say "no, we are NOT going to introduce any more SQL language features"?

Posted by Phil Factor on 30 June 2009

Oberon is now on version 7. The difference between Oberon and other current languages is that each revision makes it simpler. By coincidence, next week's 'Geek of the Week' on Simple Talk is Niklaus Wirth, the guy who wrote it, and much else besides (Pascal, modula 2). Niklaus is fascinating on the subject of Oberon.

I believe that it is much harder to write a simple language. Anyone can add complexity: that is downhill drift. It takes genius on the scale of Niklaus Wirth to write a simple language.

Oberon is still loved and used, but the separate project to create a NET version, which Niklaus wasn't involved with, hit the rocks a few years ago for a reason I've never been able to discover.

Oberon would be the dream solution for the automation of database maintenance operations since it is so clear, modular and easy to use. IronOberon! Wouldn't that be nice!

Posted by Robert on 14 July 2009

Couldn't agree more - should we be forced to use a combine harvester to clean our lounge carpets?  It won't even fit in the house!

My concern is that the essential simplicty of T-SQL has a mountain of unwarrangted complexity riding on its coattails, presumably in the hope that products that never had a hope of seeing the light of day on their own merits will somehow win market penetration.  

SSIS is a case in point - it may be "feature packed" in marketing terms but I've had .net savvy developers throw their hands up in horror just trying to get their heads around it.  And .net is a complexity swamp in its own right.  

Business users need simple to use business tools, we don't have the luxury of reading 5x1000 page manuals that articulate a design vision which for the most part comes across as a hydra-headed monstrosity of poorly articulated and unrelated ideas.

Posted by Wayne West on 17 July 2009

My two favorite SQL Server books are O'Reilly's Transact SQL Programming, released with CD for v6.5/7.0 and never updated.  Sadly, my CD somehow got broken down the middle.  The other is A Guide to Sybase and SQL Server, by McGoveran and Chris Date.  I recommend them both heartily with the proviso that we don't use =* and *= syntax any more.  And they're available for wonderfully low prices on half.com and the like.  Another goodie from 1989 is The Practical SQL Handbook by Emerson, Darnovsky and Bowman, all of Sybase.  Sadly I have yet to find a book post-v2000 that I thought worth buying.

Leave a Comment

Please register or log in to leave a comment.