So I am back hotel (yeah, not I won’t be “back home” until the 4th most likely) after speaking in Columbus yesterday, and I feel like blogging about how things went, perhaps to get advice on how you might correct/approach things.  I do two sessions usually, a design fundamentals session that went well, with scores averaging 4ish out of 5. No real “bad” reviews, and a few pretty good ones. Then I looked through the reviews for the Patterns session and a few were pretty great, but a few more were negative (2 or 3ish), with most averaging 3.5 or so for my second session. That session must be corrected..

I think a few things went wrong (listed from least to worst).

1. The crowd was a bit unresponsive.  This certainly could have been my fault, though I did hear the same thing from a few other speakers.  Perhaps Ohioans’ aren’t morning people?  Perhaps they don’t like badly told bad jokes? no clue. One guy tweeted about it (http://twitter.com/dmmaxwell/status/17097085613). Still, can’t blame the audience for being themselves.

2.  I was coming down with a bit of a cold. I didn’t realize it, but by the end of the day I felt pretty crummy.  Again, just one of those things. It was only a minor factor, and not my first off day.

3. A lot of people don’t grok why I am saying what I am saying. They understand the presentation, and claim to know all that I am saying. They say “not intermediate, not technical enough”. Look, I realize that part of my problem is that I am trying to take a subject that takes me 100 pages to express in a book and do it in a 50-60 minute time block. The problem is “technical”. How do you make “design” technical.  I spend a bit too much time on enforcing and understanding uniqueness and need a bit more stiff example of nulls.  The list of sections is:

•Normalization
•Uniqueness
•Supertype/Subtype
•Generalization
•Data Driven Implementation
•Self Documenting data
•Data Domains
•Optional Data
•Pre-calculated data

In each section I talk about some of the table designs that could serve to deal with each and make things easier to implement. (Hierarchies is missing from the list if I had more time, but it just doesn’t fit in 1 hour.)

The “reason” I speak on the topic of design is simple. Get the design right, and all of the other sessions you go to will become “next steps” in the process and not regular emergency rescue procedures.  On the forums (which I haven’t been to in a while to do some writing, speaking and vacationing. Hey something has to give 🙂 90% of the questions people ask could be alleviated by good design. Even 90% might be an understatement.

The fact is, design is all about following a very simple (to express) pattern:

1. Understand the needs of your customer and produce requirements.

2. Design structures that meet those requirements, following proper patterns starting with normalization and other common patterns and standards

3. Implement the structures.

4. Help programmers use your structures correctly (or at least do some review)

The most technical stuff is writing CREATE TABLE statements, CONSTRAINTS, and maybe a trigger now and again. The rest of the work is programming (and another session 🙂  I could teach a monkey to do syntax of commands.  Step 1 is where 60% of the problem is (and is rarely in the data architect/programmers hands).  Step 2 is the next 25% of the problem, as you need to end up with tables that match how SQL Server works best. 1% is in implementing, and the final 14 is in how the code is written. 

The problem is (and this is why I believe that so many people give up a Saturday to go to these events) every mistake is magnified in an inversely proportional asymptotic curve. Screw up requirements, and the programmers will have a mess trying to meet the actual requirements of the user.  Build bad structures, and coding is that much more difficult. And so forth. A well designed database running on a great RDBMS will leave the DBA team in more of a Maytag repairman role. Never busy fixing stupid problems, only spending time upgrading capacity to meet customer needs. Happy customers means happy you.

I am working to produce a new version of the session for Devlink and possibly PASS, so if you have ideas (if you have seen it or not), comment here, or if you want to be super mean, you can email me at louis@drsql.org.  Either way, I just want to make the session everything it ought to be (whether that makes everyone happy every time, that is the goal anyhow).