Common Database Design Mistakes

This is sage advice - but you just shouldn't have to do all that crud.

It assumes that the structure of your data is knowable upfront - but most businesses just discover this as they go along.

So the first quote is brilliant - you have to know where your going. Well even if you know where your going as a business, do you know exactly how you'll get there, will you know precisely what your data will look like?

Should it be static? I think not. We've been doing data for 30 years in basically the same way. We have good stable fast cheap open databases like postgreSQL, but they dont solve the problem. Its just too damn expensive to _change_ the structure of your data, and move your data along at the same time.

BizGeek - "Um. I thought before that there was always just one boss for any given salesperson, but now we need to change that.."

DataGeek "uhuh, yeah it would have been nice to know that upfront, ahh its gonna impact the schema and um, the code.. thats kind of nontrivial."

For a long time I could not understand why people put their valuable data into spreadsheets..losing all the important inter-relationships in the process. But its the right decision, because once they move it into a DB.. they will never ever get to change it!

There just has to be a better way.

This article made me wince. It describes a style of programming which has been common among corporate Oracle and Microsoft developers for years but seems very inefficient and outdated now. Writing a set of stored procedures in the database to call for each query you intend running has always seemed absurd to me but if you're using an ORM framework like Rails or Catalyst or whatever it's not even an option. I wonder if the author of this has even heard of things like replication, sharding, memcached or CouchDB or BigTable... Perhaps it would have been better titled "Ten Characteristics of a Very Conventional Corporate Approach to Database Design."