Re: Named Mistakes and Questionable Practices

"David Fetter" <david_at_fetter.org> wrote in message news:f4idnbhYDfUSyhrZnZ2dnUVZ_vmdnZ2d_at_speakeasy.net...
> Folks,
>
> Has anybody here made a list of canonical mistakes[1] that DB
> practitioners make?
>
> One example mistake is the One True Lookup Table aka the
> Entity-Attribute-Value table, as in this article:
> <http://www.dbazine.com/ofinterest/oi-articles/celko22>. Doubtless
> people have run across others. Ideally, such references would:
>
> * Name the mistake,
> * Describe the mistake's implementation, and
> * Show how and under what circumstances it's a mistake, as the above
> article does.
>
> Thanks in advance for any hints, tips, or pointers :)
>
> Cheers,
> D
>
> [1] Let's exclude, for the purposes of this discussion, the idea that
> SQL itself is a giant mistake and that we should now be using
> VaporWareTransRelationalDBMST--vague, questionable patents
> filed--which will eventually be a product some day. We can say that
> that horse has already been beaten well enough and is already
> deceased, if it makes people happier.
> --
> David Fetter <david_at_fetter.org> http://fetter.org/
> phone: +1 415 235 3778 AIM: dfetter666
> Skype: davidfetter
>
> He who blesses his friend with a loud voice early in the morning, it
> will be reckoned a curse to him.
> Proverbs 27:14

Search this newsgroup for a discussion entitled "Stupid Database Tricks". Among others, Google groups, maintains an archive of the newsgroup.

Also, OTLT has been discussed, in and of itself, several times. What usually happens is that someone relatively innocent shows up asking why this isn't the best general solution to the problem of lookup data. A few people usually explain how to solve the problem with a new lookup table for each type of data.

Then some whizbang artists show up to say how successful they've been with OTLT. The examples they give are generally so simple that they could have survived bad methodology and still produced a workable product.

From there the discussion goes downhill. It generally devolves into a debate between those who want dynamic data type creation, and those who favor disciplined data management.

The dynamic data type camp doesn't want either the delay of waiting for a data manager to define a new reference table or the supposed maintenance problem of having multiple different versions of the database supported in the field.

The strict data management camp tries, usually unsuccessfully, to point out that the same management and maintence issues will surface, one way or the other, no matter how you hide the existence of new data types from the DBA.

From there, it becomes another debate between the OO camp and the RM camp.

I believe this horse is dead as well. But if you want to dig it up an beat it some more, there's always Google groups. Received on Thu Jun 08 2006 - 13:59:06 CEST