It's done by lazy DBAs that don't want to have a lot of tables to maintain.
And it's done by lazy programmers who want one data entry form to maintain
all the codes. And all the work and blame for failure falls on the poor
fellow who writes the select, insert, update and delete SQL.
"Tim Cross" <tcross_at_pobox.une.edu.au> wrote in message
news:87zns33nrf.fsf_at_blind-bat.une.edu.au...
> "Brian E Dick" <bdick_at_cox.net> writes:
>
> > BTW, I have worked with this implementation before and in the long run
it's
> > a real bastard. Looks like you are trying to avoid multiple code tables
by
> > merging them into one and adding a type column. Don't do it. Use
multiple
> > tables. Otherwise, this "simplification" will cost you tons of
complicated
> > and buggy SQL down the road.
> >
>
> Oh how I wish this point could become more widespread.
>
> Out of all the db applications I have worked on over the years, this
> would be one of the most common design flaws I have come across. I
> find it difficult to understand why so many designs incorporate the
> single code table with a type field approach when all the theory
> indicates it is a bad idea (tm) and anyone who has had to work with
> such a system knows it leads to additional complications, maintenance
> problems and a common source of errors.
>
> Tim
Received on Thu Nov 21 2002 - 08:12:40 CST
