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>

Art vs. Science

Introduction

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

Please.

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?

No.

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.

Conclusion

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

Comments

 

PercyReyes said:

Andy:

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' http://www.simple-talk.com/content/article.aspx?article=472  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. [...]

http://www.pythian.com/news/3404/log-buffer-154-a-carnival-of-the-vanities-for-dbas

July 17, 2009 2:34 PM

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