THE SQL Server Blog Spot on the Web

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

Andy Leonard

Andy Leonard is CSO of Linchpin People and SQLPeople, an SSIS Trainer, Consultant, and developer; a Business Intelligence Markup Language (Biml) developer; SQL Server database and data warehouse developer, community mentor, engineer, and farmer. He is a co-author of SQL Server 2012 Integration Services Design Patterns. His background includes web application architecture and development, VB, and ASP. Andy loves the SQL Server Community!
Note: Comments are moderated. Spam shall not pass! </GandalfVoice>

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

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

Comments

No Comments

Leave a Comment

(required) 
(required) 
Submit

This Blog

Syndication

My Company


Other Blog

Check out my personal blog...
http://andyleonard.me

Contact Me

Twitter: @AndyLeonard
Email: andy.leonard@gmail.com

Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement