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
Andy:
you’re right, but I considered more art than science.
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.
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."
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.
“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