January 18, 2020, was the last time I stood in front of a live group of people and spoke about anything. It was at the location where I did my first SQL Saturday presentation, back at the first SQL Saturday in Nashville. Speaking at the time was a normal thing for me, having done 5-8 sessions a year since early in the century. I have never been exactly the most comfortable speaker, but repetition builds confidence (at least in the fact that my head will not actually explode if I get really nervous.)

Due to a variety of situations, I have not been back in front of a group speaking about anything since that day. Clearly, you all know about one thing that got in the way. Still, even after that, a few orthopedic issues have cropped up that made me cancel two events (in Atlanta 2022 and Jacksonville 2023). These were the first two times I have ever canceled on a SQL Saturday event. I think just the third time of any type of conference… the other was a PASS Summit, where my hip replacement broke the week before it, and the MVP Summit (just walking along, and it snapped). Yes, I am an orthopedist’s dream patient in that I help keep them busy!

On July 15, I will be at SQL Saturday Columbus, doing the same session I did back in 2020. It is my database design session, and it is pretty much the same one as I did back then (and have for years). Proper relational database design really hasn’t changed much fundamentally other than engines just get better at compensating for bad designs.

This is the abstract:

Relational Database Design Fundamentals

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

Looking forward to getting back to Columbus. I haven’t been to their SQL event in many years!

What’s Next?

Sheesh, can’t I even finish that event? The answer to that is usually “No.”  Constantly planning what is next. So this Relational Database Design topic, is it time to retire it? No way. It is a critical topic that needs to be heard by so many. I plan to go cross-platform with it in the future once I reach that level of knowledge of PostgreSQL and /or MySQL.

For my next presentations, I have intentions of prepping two new presentations in the near future:

•  SQL Server Graph Demo. A pretty deep demo of SQL Server’s graph features, torn from the examples in my graph book that just came out. 
• Concurrency in PostgreSQL. A topic I was really interested in concerning SQL Server has piqued my interest in PostgreSQL too. They seem to use a mix of locks and MVCC, which is quite interesting to me from my time with SQL Server’s locking model as well as MVCC in the In-Memory objects. Still working on the material for this one, and it may take me a while!

Mind you, I said I have “intentions” of prepping. Life has a way of overwhelming you at times. And orthopedic procedures take more out of you than I want to admit.

Either way, will I see you in Columbus? If not, I plan to be in Orlando and Atlanta (date/location not announced so I am just hopeful as I write this, so I’m not 100 sure when/if) later this year, as well as PASS. Not speaking at PASS (but may have jobs to do), and not sure if I will submit to speak to the other conferences, but do plan to be there in either case.