Boy does time fly, and it is already mid January. The holidays flew by, and now the Christmas tree and (most of) the Christmas décor has been boxed up in the attic (yeah, there is a Santa on a shelf staring at me that he needs to be put up!). The college bowl games are over, rendering all college teams a blissful 0-0 record again, and in the SQL Server community area, one of the very first events is upon us: SQL Saturday Nashville.

This year, I am speaking in the first slot at 8:30, talking out that favorite topic of mine: The fundamentals Relational Database Design. Even if you are not going to be building databases and are just writing code to use them, understanding why the data architect gets really grumpy when a database has 2 tables with 1000 columns each (even though it “gets the job done, I suppose”) will at least let you know the issues you might run into with less than optimal designs.

I have been doing a variation of this presentation for 20 years, and while the reasons to build a relational database a certain way haven’t changed, a lot has changed as to why it is so important to at least understand the basics. The amount of data being stored, even for simple transactions, has skyrocketed over the years, and businesses are looking for more information from their data than just knowing that a product was shipped, and that we got paid for it. The big question people want to know is “how do we get them to do it again with the least amount of effort?” To do that calculation, the better the data, the easier the calculation.

The abstract for the presentation is:

Data should be easy to work with in SQL Server if the database has been organized as close as possible to the standards of normalization that have been proven for many years, but are often thought of as old-fashioned. Many common T-SQL programming “difficulties” are the result of struggling against these standards and can be avoided by understanding the requirements, applying normalization, as well as a healthy dose of simple common sense. In this session I will give an overview of how to design a relational database, allowing you to work with the data structures instead of against them. This will let you use SQL naturally, enabling the query engine internals to optimize your output needs without you needing to spend a lot of time thinking about it. This will mean less time trying to figure out why SUBSTRING(column,3,1) = ‘A’ is killing your performance, and more time for solving the next customer problem.

Of course, all of this is a very tall order for an hour, and when I did this as a webinar for SentryOne with the fabulous Kevin Kline as my color commentator, it took about 2 hours, over two sessions (the second one is here). So come to see it live, or check it out on your own pace because you had rather go see Monica Rathbun talk about performance. Hey, if you build tables and don’t care about the right way to design a relational database is probably a good idea anyhow. Though I do expect one of her items might be (don’t do a crappy job designing in the first place!)

Hope to see you there!