“It’s book writing time in Tennessee!” Ok, so I am actually in the Seattle airport waiting for my flight in around 3 hours, watching the TN – Mississippi game on my Slingbox, which was the inspiration for the title of the post (John Ward, the radio “voice of the Vols” before Bob Kessling (who does a great job too) used to proclaim it to be “Football Time in Tennessee on the radio before every game.) Enough of that.

My blogging has been very lean for a while now, mostly due to writing a book on the DMVs with Tim Ford, and a large part of that was that I just didn’t love the DMV subject on the level I do design. Design is so exciting to me because it is a topic that is gets things going. Do it wrong, and you need DMVs, profiler, and a lot of work to keep things going. Performance tools, for the average dba, are about survival. And survival is a fun challenge occasionally, but it gets really tedious.

This isn’t to knock good survival skills… In fact, it is the unprepared person who often needs these skills the most. And it is the designer that doesn’t understand the platform he is designing for that is most likely to get it wrong. I am not just talking about the academic living in his glass house telling you how you are wrong (I have no particular person in mind when saying that, I promise), but rather the more likely scenario is the functional architect/coder designing a user interface/object model (even a wonderful one) just tries to translate that directly into a relational database. They are wildly different things created for wildly different reasons.

So this impedance mismatch between the two technologies opens a chasm between the two camps that you could drive an aircraft carrier through. And it needn’t be this way. Over the years, the ORM technologies have gotten better and better, and to build a reasonable system with them isn’t rocket science. Unfortunately, the problem is that we can’t get along, and when the dba tries to articulate why the implementation isn’t particularly excellent, they can’t do it in a convincing manner.  The book I produce is for especially for you. Even if you never get a chance to be the architect of the database  (the book is definitely for aspiring architects as well) knowing what a database should look like and WHY it should be that way may help you convince the architect that there is a better way. And I know from talking to the people who use correctly and build at least one of the ORMs out there that it is definitely possible to build a proper ORM-Relational mapping that will leverage both platforms well, if not perfectly.

Then, your DMVs, profiler, performance monitoring tools, etc can be relegated to real emergencies, generally happy emergencies like when your website has near denial of service levels of activity because your company’s business shoots to the moon overnight instead of daily trying to let one of your users attempt to do day to day business without an extreme amount of contention, looping, cursoring, etc.

Over the next 12 months (+/- N months, of course) I will be rewriting much of the book to make it more natural to use, more valuable to people who have previous editions, and more valuable to people who want a higher page count because they own a parakeet and want to line the cage with only the best technical manuals.  So why should you care?  Well, I am going to be asking for your help in a few ways.

1. I will be posting the outline/table of contents for opinions over the rest of 2010

2. I will be posting bits and pieces of the book that I am “uncomfortable” with to see what people think.

3. I hope to get a reasonable number of people to review the book ahead of printing

So here I go again…only this time it’s personal…