Re: OT: Database design question
- From: Jared Still <jkstill@xxxxxxxxx>
- To: sfaroult@xxxxxxxxxxxx
- Date: Mon, 9 Jan 2006 15:32:23 -0800
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> 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).
>
> HTH
>
> Stéphane Faroult
>
Other related posts:
