Assuming all goes as planned, I will be in Columbus, OH this Friday night and Saturday for SQL Saturday 75. I really love SQL Saturday events the best of all of the events because they are very intimate in nature. As a fairly antisocial person, I sometimes get overwhelmed by the size of other events, even the SQL Rally was just barely in my comfort range. Here the number of people and size of rooms just feels like home, like you are shooting the breeze with a group of friends.

My session will be at 9:00 AM (full schedule), so don’t be late!

Characteristics of a Great Relational Database
When queried, most database professionals would mention normalized as one of the most important characteristics that tell the difference between a good and bad database design. I won’t disagree in the least, but there is so much more to be considered.  Even if you did a great job of normalization, poor naming, poorly implemented keys, too many or too few indexes, and so on can derail your design.  In this session I will present seven primary characteristics of a design that differentiates between an ugly design that will have your colleagues nitpicking you to death and one that will have them singing your praises. Characteristics such as comprehendible, documented, secure, well performing, and more (including normalized, naturally) will be discussed.

It is the second time I will do this presentation, and the first time where I can see the faces of the recipients, so it will be nice to gauge how people like it. It is a lot of fun actually, though no matter what I am talking about I want to talk more about normalization, which I believe is the key to improving the databases of the future. So many of the session that are given at these things are geared towards systems that are already screwed up and limping along, and I really want to evangelize the merits of doing it right.  That is where this presentation fits in, the time period between design and performance tuning, where you determine the future work that is done with the system. Is it well performing, understandable, easy to maintain and use? Or does it take a crew of ten thousand DBAs doing nothing but putting their fingers in the leaks to keep the thing running?

And don’t forget all of those BI sessions too… The better you do with the relational database, the easier the dimensional designer/implementers have it too.

Anyhow, I hope to see you all there (well, not all of you, just the SQL nerds who are reading this. The history buffs who are still wondering why we are going to be inside the founder of our continent this weekend, well, you I feel sorry for you.