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

A problem I must solve about speaking

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).

Published Sunday, June 27, 2010 8:13 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

 

James Luetkehoelter said:

I'm sorry Louis, that's a drag. Been there, gotten low scores like that...

Sadly (and I mean that), I think that when people go to presentations they want 2 things - 1) Something pithy they can immediately take to their work and make a big splash and 2) something directly pertaining to the work they do (context).

This of course rules out more fundamental talks like you're describing, and the kind I've tried to give in the past. Of course not everyone is like this, and I'm sure there were 4's and 5's with great comments, but I fear that the majority is looking for the quick fix, not the long term advice.

June 28, 2010 12:36 AM
 

Mark Freeman said:

For what it's worth, I found the jokes to be amusing and appreciated them. They just didn't strike me as "laugh out loud" funny. (Maybe it was just sleep-deprivation on my part.) But they did help keep things from being too dry.

I agree with you that it would have been inappropriate to get into syntax in a design session like this. I think the focus of the presentation was spot on.

I've been doing database design for a long time, so some of the Patterns presentation (I didn't attend your first session) seemed obvious to me. Some of it I disagreed with (or at least I didn't see a good example of when Subtypes/Supertypes would be better than a different approach), and some of it gave me good ideas. Anything that gets me thinking in a different way is a good thing, whether I decide to do things that way going forward or not.

All in all, I'm glad I attended your session.

June 28, 2010 12:41 AM
 

Saggi Neumann said:

Hey Louis,

I agree with James. DB design is something you should do a whole day seminar (preferably 3 days...) with hands on experience on the important aspects such as getting user requirements  (partial as they almost always are), debating, etc.

I think that you can do a 1 hour session on design if you talk about bad/complex designs and how to overcome the problems they cause which would eventually help the audience more as most of our time is spent on fixing someone else's databases and applications.

Cheers,

S. Neumann

June 28, 2010 2:20 AM
 

drsql said:

>>For what it's worth, I found the jokes to be amusing and appreciated them. They just didn't strike me as "laugh out loud" funny. (Maybe it was just sleep-deprivation on my part.) But they did help keep things from being too dry. <<

That is the goal really. I just want to keep it from being dry, but more I hope for interaction on questions and stuff.  I really need more time than I have to get too far, and seeing if people get it, don't get it, or whatever is interesting.  I don't want to bore the pants off of people.

>> (or at least I didn't see a good example of when Subtypes/Supertypes would be better than a different approach)<<

There too is the problem with a short session. Just finding something that is relatively plausible is hard enough, much less something that would apply.  I will definitely be modeling a bit more on the supertype subtype example to show how things will expand out and be easier to visualize.  But the goal is more to start people thinking about the kind of stuff you can do.

Usually that presentation goes better, but I have to admit, I have been itching to make some sort of changes and I think that I have some ideas to really make some good changes.

>> talk about bad/complex designs and how to overcome the problems they cause which would eventually help the audience more as most of our time is spent on fixing someone else's databases and applications.<<

I think this might be a really good way to go, show typical patterns of dev that kill us and the correct way to make it work without issue.

Now I just need to come up with feasibly bad examples that aren't directly pulled from experiences that will cause the people who made them aren't offended :)

Thanks to all of the comments. They certainly help, and am regularly willing to take negative comments to make things better.

June 28, 2010 8:00 PM
 

BuckWoody said:

Design is REALLY hard to present in an hour. I get my lowest scores on my design talks, and I've spun them every way till Sunday to get them across. I think the key is setting expectation - I tell everyone right at the beginning what we are going to accomplish in the preso, and tell them it won't hurt my feelings if they bail.

But I think design is so important that I keep giving the talks. It just needs to be hammered home. So keep the faith.

June 29, 2010 11:41 AM
 

Louis Davidson said:

So, clearly I haven’t blogged in quite a while, even forgetting to blog about SQL Saturday 51 event we

September 9, 2010 9:12 PM

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