Re: OT: Database design question
- From: Nuno Souto <dbvision@xxxxxxxxxxxx>
- Date: Tue, 10 Jan 2006 18:57:37 +1100
Well, it's certainly what it was invented for: to avoid
the problems caused by "generic" databases.
And why those (the generic dbs) should never be allowed to
go ahead: they really solve nothing and only create longer
term problems. Then again, "long term" is something
contrary to modern "design" techniques, so take your pick....
--
Cheers
Nuno Souto
in sunny Sydney, Australia
dbvision@xxxxxxxxxxxx
Jared Still said,on my timestamp of 10/01/2006 10:32 AM:
Hi Stephane,
I think this might be better stated that one should strive to create
a normalized design.
If you do so, then the problems you mentioned will be avoided.
--
Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist
On 1/9/06, *Stephane Faroult* <sfaroult@xxxxxxxxxxxx
<mailto:sfaroult@xxxxxxxxxxxx>> wrote:
Giovanni,
You are on a slippery slope. You have identified quite correctly one
of the issues (and someone pointed at performance too). But you should
also tell your customer that any type of so-called "meta" design means
that you won't be able to implement foreign keys nor integrity
constraints (unless you bend over backwards in triggers). For instance,
some of your item attributes will be numbers, some characters, which
means that everything would have to be stored as a string. If someone
mistypes a O (letter) for a 0 (digit), no way to check it. Consequence,
queries may return wrong results. Even if you try to segregate the
values by type, you will have no way to check that values are valid or
within reasonable bounds. Unless most of the code is made of validity
checks in the application code (no protection against the fat-fingered
SQL*Plus user).
It's a much better solution to have a generic ITEMS table, and a
specific table by type of item (subtyping).
--
//www.freelists.org/webpage/oracle-l
Other related posts:
