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

Art vs. Science


I read Phil Factor's Database Weekly editorial entitled Basically Available, Soft State, Eventually Consistent. I agree with Phil's conclusions about special-purpose databases that purport to be "RDBMS killers."


How Much Paint?

Some argue our profession is science. I can see that. Some argue it's a passion. I represent that remark. I consider the database profession a craft. That makes it part art and part science.

Let's set aside the science for a moment and consider the art. And let's compare our art to that of traditional artists; painters in this case. How do we measure the artistic value of a painting? Is it by how much paint is applied to the canvas (or other medium)? Is it how fast the painting was completed? Is it how many or few colors were used?


I chose these metrics intentionally. They map nicely to metrics we regularly measure for databases.

The Point

The point is simply this: Art is often judged with terms such as "intrinsic beauty." How does this translate to a database solution? Elegance.

Is elegance the most? No. Is elegance speed? No. Is elegance minimalist? Maybe.

"Then what is your point, Andy?" I hear you thinking. I'm glad you asked: Elegance is a solution crafted to meet the need(s).

When More Is More

More paint is good when you're trying to cover the most media economically. Faster painting is good when you have a limited amount of time to meet some deadline. Few colors is good if you need to limit resources, more colors is good if contrast or busy-ness is a goal.

In database work, elegance is achieved in balance. Balance is about what's best for the life of the database solution. A lot plays into this - available hardware or hardware budget, development deadline, and the skills / comfort-level of the support staff. That last point cannot be underestimated. I've altered deliverables to design a solution the current staff can support.


There are certainly times when all you care about is performance, or scalability, or meeting a deadline. All of these are important. But how important changes with each database solution, and balancing these factors is the art of database design.

:{> Andy


Published Saturday, July 11, 2009 11:46 PM 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



PercyReyes said:


you're right, but I considered more art than science.

July 12, 2009 1:04 AM

Phil Factor said:

Thanks for the plug, Andy. Database design can be an art, but only after one has mastered the science.

Occasionally, I've sat back from creating a database application with the same sense of achievement as I get from creating a good painting or poem.

My happiest databases have been created by me alone. I wrote an article about one of those occasions. 'Creation by Committee'  The artist that I used in the story was Michelangelo.

July 12, 2009 4:39 AM

Tim Mitchell said:

These BASE systems may represent a narrow threat to two different segments.  The first group is those large and highly specialized systems such as those mentioned in Phil's article.  The other group is the sloppy databases designed as a simple add-on to an application, just a "place to store bits", without regard to referential integrity or proper indexing. Using Andy's painting analogy, I liken the latter group to painting the inside of a backwoods auto mechanic's shop.  "Yes, the place needs to be painted, but we're not in the painting business so we don't care if it's sloppy."

July 12, 2009 4:11 PM

Duke Ganote said:

The issue boils down to: how stand-alone is the application?  If it's totally stand-alone, then the data implementation can be solely for the convenience of the app designer.  But those apps are few and far between: most companies want to see reports, gauge effectiveness, share a customer master and a product master and to measure ROI.  Stand-alone apps are rarely designed for that "enterprise vantage."

If the data is a shared resource, then it's an enterprise resource and needs to be managed and designed as such.

It's like the difference between a go-kart and a Hummer.  They each have different degrees of "beauty."

The go-kart is lots easier to build, and may have some specialized military usage.  But I'd rarely choose one for battle.

July 13, 2009 11:52 AM

Log Buffer said:

"Andy Leonard has been thinking about the profession of the DBA, in light of non-relational DBMSs, and concludes that it’s a question of Art vs. Science. [...]

July 17, 2009 2:34 PM

Leave a Comment


This Blog



My Latest Book:

Community Awards

Friend of Red Gate

Contact Me


Privacy Statement