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_at_iinet.net.au
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* > 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).
>
--
http://www.freelists.org/webpage/oracle-l
Received on Tue Jan 10 2006 - 08:57:37 CST
