On July 22, I will be heading over to Nashville, TN to be the second speaker at the newly formed Music City Data User group. The group was started by Jason Romans with help from Kevin Kline (and I may have voiced a few opinions to my coworker/friend Jason as well.

Looking forward to crossing Monteagle Mountain and heading to my second home next Wednesday. (That stretch of highway is immortalized by Johnny Cash, in his song by that same name. Luckily transportation is a lot safer these days)

The session

I have to admit, I have been wanting to do a different session. I had these grand plans to sit down and adapt my concurrency session I did a few times in years past to include the new optimized locking…but well, I got sick for a few weeks and am now just pulling out of that dive. So I decided that I would do my very favorite session about database design. And to be fair, who doesn’t need more discussion of the fundamentals of database design.

I have been working on this session over the years since I first did it at the Nashville user group, so there are fundamentals in there, but it gets more and more fun to do as I have more and more experience with databases, especially on more than just SQL Server. The abstract is at the end of this post.

So if you are near the Nashville area and you am work with data, click the following along and meet me at Vaco in Nashville (in the Brentwood area) for what will hopefully be a fun and informative session on Wed, July 22, just smash the following link and I will see you there.

Link to register

Relational Database Design: Work With SQL Server, Not Against It

Data should be easy to work with in SQL Server when the database is organized according to proven relational design and normalization principles. Although these standards are sometimes considered old-fashioned, many common SQL programming difficulties result from working against them.
In this session, Louis will provide an overview of relational database design and explain how thoughtful normalization, clear requirements, and a healthy dose of common sense can help you create data structures that work with SQL Server instead of against it.

Good database design allows you to write SQL more naturally and gives the query engine a better opportunity to optimize your requests. That means spending less time trying to determine why expressions such as SUBSTRING(column, 3, 1) = ‘A’ are hurting performance—and more time solving the next customer problem.

If I can keep just one database from making a mess just so the UI devs can save a few joins… well it might just be the first time. But at least you will join me in understanding why poor design hurts so much and you can join me tilting at tuples.