Louis Davidson
Database design writer, speaker, and doer.
Cleveland, Tennessee, United States
Actions
Louis, also known as drsql (despite the lack of any post-graduate education) is a database design fanatic and has been for over 25 years when he started writing his first book on the topic. He has been a blogger, writer, editor, speaker, and champion of the idea that if you start any project with a firm foundation, it will serve you well for years and years. You can find out more on his website at drsql.link.
Badges
Area of Expertise
Topics
Who Cares About Relational Database Design?
It has been nearly 45 years since the concept of a relational database management system (RDBMS) was written down by Edgar Codd. If you work with any technology besides databases, something written down 45 minutes ago may already be obsolete. So why does relational design still matter?
I will answer that question by showing how to design a database, including the common normal forms and how they make data easy to work with (even if you are not using an RDBMS). Many typical database programming "difficulties" result from struggling against how data should be structured and can be avoided by applying basic normalization techniques. Most of these techniques are common sense, but some subtleties cause every designer to occasionally struggle with them, even when the code gives the correct answer (For example, why can't you write:
WHERE ColumnName like '%son'
and the optimizer figure out how to use an index?).
When Transactions Collide: Writing Concurrency-Safe T-SQL
Concurrent workloads can cause seemingly well-written T-SQL to cause blocking, return inconsistent results, or even lose updates in ways that are difficult to reproduce. Through practical demonstrations, this session shows how locking, row versioning, and transaction isolation levels affect performance and data integrity. Attendees will learn to diagnose common concurrency problems and choose isolation settings and coding patterns that protect data while minimizing unnecessary blocking.
Fabric Data Warehouse: Metadata-Driven Transformations from Source to Report
Use Fabric Data Warehouse to take one dataset from an external source to a Power BI report. Using the foundation of T-SQL and INFORMATION_SCHEMA views, build a metadata-driven process to create mappings to standardize names and types, reject bad rows, capture history, and create a reusable base layer. Shape data into facts and dimensions, publish a reporting view, then build a semantic model and report. Leave with an end-to-end solution, validation checkpoints, and a metadata design to repeat with your own data as new tables arrive.
Sharing is Caring and Writing is Sharing
Of all the professional development advice that floats around on the Internet, one piece of advice has always stood out to me the most. Write. Start your own blog, write an article in a magazine, maybe even write a book. It is definitely great advice, but what does it really mean?
In this session, I will share with you my experience as a writer of many blogs and books. In the past 25 years of staring at a keyboard looking for the next word, I have encountered so many different types of writers and editors. Lots of great stuff that has been written, and the not-so-great.
I will cover how putting yourself out there in the written word is a great thing to do, but I will also share some of the negatives. Whether you have considered writing about technology or not, this session will hopefully give you a feel for the pros and cons of the process.
Dimensional and Relational Design Differences
In relational database design, the main objective is to mirror the database structure as outlined in the requirements to ensure data integrity. While this approach may sometimes be challenging for users of the database, the difficulty should primarily indicate the complexity of business needs rather than flaws in the design.
Conversely, whereas BI designs must also adhere to the requirements, usability is also especially important in your designs. Small design errors can result in analytic mistakes that have huge business implications, even when the data is technically correct. In this lightning talk, I will highlight a significant mistake I made in my initial large star schema project that haunted me for years.
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.
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top