To design or not to design?

PingBack from http://topsy.com/tb/bit.ly/6OM4YU

There is a huge gap between over thinking a design and solid design principals. Databases are one of the few things that respond poorly to haphazard growth. It isn't like you put in a bad line of code and can just back it out. DB's are much more difficult to refactor and generally harder to maintain and do require some thought to it. I do agree with most of the stuff in Evolutionary Database Design though it is light on integration and testing. Databases by their very nature are expected to scale. I almost never encounter a development shop that does proper load testing. Like this paper, 99% is focused on functional testing and non-breaking changes. I've seen poor database designs with lots of organic growth almost put companies out of business when they tried to reach for the next level and scale up to meet demand.

It's like shaping a bonsai tree, controlled growth. I've never been a fan of the marble sculpture where one small error ruins the whole design.

-wes

Wes,

I definitely agree that "I've seen poor database designs with lots of organic growth almost put companies out of business when they tried to reach for the next level and scale up to meet demand."

However, for each successful startup and or project there are several failed ones. Many of those failures spend on design too much, spend too much effort trying to get it absolutely right the first time, and run out of resources...

It is probably very difficult of possible at all to include such failures in our stats. Which leaves me thinking: if so many successful projects exhibit poor database design, doesn't it tell us something?

ok! let's go write some code then!..