THE SQL Server Blog Spot on the Web

Welcome to SQLblog.com - The SQL Server blog spot on the web Sign in | |
in Search

Louis Davidson

Why I love to (and am starting again) to write about design

“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…

Published Saturday, November 13, 2010 12:37 PM by drsql

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

Prakash Nadkarni said:

Hi David,

I've been reading your excellent "Ten Common Database Design Mistakes". I agree strongly with all your points except the one about domain values. See my counter-argument on

http://ycmi.med.yale.edu/nadkarni/domainlists.htm.

I tried responding on Simple-Talk, but the site is broken - there's no way to post a comment there.

My E-mail, in case you find any holes in my arguments, is

Prakash.Nadkarni@yale.edu

best regards,

Prakash

November 16, 2010 7:00 PM
 

drsql said:

Prakash, thanks for the comments here on a different post.  I will post a blog about it in a bit because I obviously still feel the same way about the one domain table concept. It might be a few days but I don't want to start it up here (and I want to get more opinions which will happen if I blog it.

November 16, 2010 11:22 PM
 

Louis Davidson said:

  Early in 2007, I wrote an article for Simple-Talk called Ten Common Database Design Mistakes ,

November 20, 2010 10:46 AM

Leave a Comment

(required) 
(required) 
Submit

This Blog

Syndication

Links to my other sites

Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement