Re: OT: Database design question

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).

>

> HTH

>

> Stéphane Faroult

>