THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

Andy Leonard

Andy Leonard is an author and engineer who enjoys building and automating data integration solutions. Andy is co-host of the Data Driven podcast. Andy is no longer updating this blog. His current blog is

More on Elegance in Database Design: Complexity


I wrote recently on the importance of elegance in database design (Art vs. Science). In that post I wrote "Elegance is a solution crafted to meet the need(s)." I'd like to elaborate on that point, as it is often the source of some confusion.

Elegance vs. Complexity

First, a couple statements:

  1. An elegant solution will be as simple as possible.
  2. Some complexity is unavoidable.

So what's the answer on complexity? Balance (again). I can't understate the importance of refactoring in reducing complexity as an application, database, or solution matures. A database may start with a single schema (dbo), large tables populated with a mix of types of data (not to be confused with data types).

Refactoring a database includes identifying opportunites for normalizing. And (gasp) opportunities for denormalizing. The former will occur when building transaction processing databases, for example; the latter, certain data warehouse schemas. In short, "it depends" (to quote Andy Warren).

Why Reduce Complexity? 

Reducing complexity is obviously better for end users. That's a given. But who are the end users of your database design? (Note, I did not ask "Who are the end users of your database?") Our end users are developers. They interact with the database according to the rules we database professionals establish. Depending on the nuances of our development style and the dictates of the particular project, we design and develop the database differently.

Maybe we start as described above, but don't really allow developers to see that part. How in the world would we accomplish that? Building an API consisting of stored procedures and views is one way. Then, if the underlying table structure changes, or the table moves to a different schema, or any number of changes are made in refactoring to normalize, denormalize, or performance-tune the database; our end-users (the developers) are none the wiser. 

Masking complexity in this way works.

Your end-users will appreciate it. The folks who maintain the database when you're on vacation (or after you win the lottery) will also appreciate it.


Managing complexity is one part of desgning elegant of a database solution.

:{> Andy

Published Tuesday, July 14, 2009 8:00 AM by andyleonard

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS



rosie aleman said:

As someone new to the field, I appreciate this simple explanation of the importance of elegance in design.  I found my databases quickly growing unwieldy.  

November 7, 2015 1:17 PM

Leave a Comment


This Blog



My Latest Book:

Community Awards

Friend of Red Gate

Contact Me


Privacy Statement