When the next object-persistence boat comes in.

Phil Factor, 2009-06-22

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.

Rate

Share

Share

Rate

Related content

Database Mirroring FAQ: Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup?

Question: Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup? This question was sent to me via email. My reply follows. Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup? Databases to be mirrored are currently running on 2005 SQL instances but will be upgraded to 2008 SQL in the near future.

Robert Davis

2009-02-23

1,567 reads

Networking – Part 4

You may want to read Part 1 , Part 2 , and Part 3 before continuing. This time around I’d like to talk about social networking. We’ll start with social networking. Facebook, MySpace, and Twitter are all good examples of using technology to let…

Andy Warren

2009-02-17

1,530 reads

Speaking at Community Events – More Thoughts

Last week I posted Speaking at Community Events – Time to Raise the Bar?, a first cut at talking about to what degree we should require experience for speakers at events like SQLSaturday as well as when it might be appropriate to add additional focus/limitations on the presentations that are accepted. I’ve got a few more thoughts on the topic this week, and I look forward to your comments.

Andy Warren

2009-02-13

360 reads