Stupid Database Tricks

From: Laconic2 <laconic2_at_comcast.net>
Date: Fri, 18 Jun 2004 09:50:11 -0400
Message-ID: <W6KdnWuuoukob0_dRVn-sQ_at_comcast.com>



Here's my list of the top ten stupid database tricks:
  1. We never defragement the disks that hold the database files. Data might get corrupted!
  2. We know that indexes speed things up. So every column has an index!
  3. We found that indexes tend to slow things down. So we made a rule against compound index keys, and indexes that allow duplicates!
  4. We want the updates to be simple and fast, so we don't have any referential or entity integrity constraints in the database. If you code the queries correctly, it'll weed out all the bad data anyway!
  5. We have one big lookup table. The column marked CODE_TYPE isn't documented anywhere. But it's not a problem, because each object knows what type of code it's interested in.
  6. The database isn't documented anywhere. You just have to keep asking the programmers! Besides, we want to be able to invent new types of data dynamically, so we can't afford to wait for the DBA to update the metadata.
  7. There's a complete data dictionary for the database, but it's five years out of date. A lot of things have changed. Nobody ever uses it, because so much of it is wrong. And we can't budget a project to bring it up to date, because nobody ever uses it, anyway.
  8. It's too early to worry about normalization. We have to get version one of of the application to the marketplace!
  9. It's too late to worry about normalization. Version one is already in the field. If we change the schema now, we'll alienate the existing customer base!

And the number one stupid database trick:

  1. We like to keep things simple. Everything in the database is stored in one giant table!
Received on Fri Jun 18 2004 - 15:50:11 CEST

Original text of this message