

Common Database Design Mistakes - alexk
http://www.simple-talk.com/sql/database-administration/ten-common-database-design-mistakes/

======
gord
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.

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

