Re: Stupid Database Tricks

From: robert <gnuoytr_at_rcn.com>
Date: 18 Jun 2004 19:07:15 -0700
Message-ID: <da3c2186.0406181807.3d511df_at_posting.google.com>


"Laconic2" <laconic2_at_comcast.net> wrote in message news:<W6KdnWuuoukob0_dRVn-sQ_at_comcast.com>...
> Here's my list of the top ten stupid database tricks:
>
> 10. We never defragement the disks that hold the database files. Data
> might get corrupted!
>
> 9. We know that indexes speed things up. So every column has an index!
>
> 8. We found that indexes tend to slow things down. So we made a rule
> against compound index keys, and indexes that allow duplicates!
>
> 7. 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!
>
> 6. 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.
>
> 5. 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.
>
> 4. 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.
>
> 3. It's too early to worry about normalization. We have to get version
> one of of the application to the marketplace!
>
> 2. 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!

0. we like to keep things familiar for the 60 year old COBOL programmers who wrote version 1. we keep each table in its own file. we prefer to manage integrity in the application.

  • that's a quote. i'm really not kidding

robert Received on Sat Jun 19 2004 - 04:07:15 CEST

Original text of this message