SQL 103 – Introduction to Database Design and Architecture

I’m starting a new blog series to accompany the session I’m presenting at SQL Saturday #87 in Louisville! This session will cover the basics of designing a database from a developer’s point of view. During the class I’ll only have an hour, but in these blog posts I’ll be able to dig in a bit more.

As the blog posts go live: I’ll include links here, so you can read all the posts as a unit.

During this first class I will gloss over the details of the different normal forms. I’ll even skip over the details on what T-SQL you’d use to build database objects. Honestly, I’ve covered that in the other series (101, 102, 201). You can find the scripts you’d need there. It’s not that they aren’t important; you simply have to start somewhere, and why not jump right into the design and architecture process.

This series will take the approach you’ll experience in most design meetings. We’re going to talk about accomplishing a specific goal using database technologies, and we’ll kick around solutions until we pick “the best one”, and then move on. Through this class, you’ll learn enough to participate in these meetings. The trick is you’re going to have to participate in many of those meetings in order to master all the skills. Nothing beats practice!
And now… let’s dig into the articles.

Normalized or Denormalized Design

Normalized Table Design

Relating your tables

Prevent Dirty Data

Designing Views

Adding Indexes

If you have any questions, or if you want me to cover something specific in this series, let me know! After all, I’m building this content for you!

By Shannon Lowder

Shannon Lowder is the Database Engineer you've been looking for! Look no further for expertise in: Business Analysis to gather the business requirements for the database; Database Architecting to design the logical design of the database; Database Development to actually build the objects needed by the business logic; finally, Database Administration to keep the database running in top form, and making sure there is a disaster recovery plan.


    1. If you need to build something mission critical for your company, and you don’t have the skill set to design and implement your own database, I would say outsource it. But if you need something as a prototype, or something that isn’t going into production, absolutely give it a shot yourself! You can really only learn database design, by trying, and learning from your mistakes along the way.

Leave a comment

Your email address will not be published. Required fields are marked *