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.