More on Elegance in Database Design: Complexity

Introduction

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.

Conclusion

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

:{> Andy

Andy Leonard

andyleonard.blog

Christian, husband, dad, grandpa, Data Philosopher, Data Engineer, Azure Data Factory, SSIS guy, and farmer. I was cloud before cloud was cool. :{>

One thought on “More on Elegance in Database Design: Complexity

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

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.