Re: A searchable datastructure for represeting attributes?

None of this is strange to Ted Codd, you know. It's just going beyond third normal form, into 4 or 5. The problem, however, for we poor DBAs, is performance.

Paul

"Obnoxio The Clown" <obnoxio_at_hotmail.com> wrote in message news:3c7e92b0.103562675_at_News.CIS.DFN.DE...
> On Thu, 28 Feb 2002 15:01:58 -0500, no_spam_for_me_at_thankyou.very_much
> wrote:
>
> >Yes it is very good and normalized in Dr Codd sense but you still store
100
> >times more information than you need to store with what I described in
> >approach_1. That is absense of a key indicates a default of make=toyota
> >and color=blue. Yes I can see how this is anathema to relational design
but
> >it is a real world problem.
>
> Disk is cheap, certainly cheaper than the TCO of maintaining an
> awkward design.
>
> >The closest analogy is LDAP systems. They are implemented on top of
> >Relational Databases yet they allow to assign a separate schema for every
> >node in the tree and do not waste space for Attributes that have no value
> >assigned to them. I was wondering if there was some established way of
> >representing this kind of situation in the Relational world and that was
> >the essense of my question.
>
> Well, it is horrible, but the closest thing I could think of would be:
>
> -- NOTE: SQL may not be syntactically correct, I'm just trying to
> illustrate the idea
>
> create table data_that_fits_the_relational_model (
>
> serial_no serial primary key,
> -- rest of table definition
>
> );
>
> create table default_values (
>
> attribute_name char(128) primary key,
> attribute_value char(128) -- or whatever
>
> );
>
> create table exception_values (
>
> serial_no integer not null,
> attribute_name char(128),
> attribute_value char(128) -- or whatever
> primary key(serial_no, attribute_name)
> );
>
> Or you could use VARCHARs which don't fully eliminate wasted space but
> do minimise it.
>
> Or you could use the OR approach I outlined earlier. But really, if
> you're just trying to save on disk and you have a lot of records,
> you're looking at it the wrong way.
>
> Disk is cheap, certainly cheaper than the TCO of maintaining an
> awkward design.
>
Received on Thu Feb 28 2002 - 17:17:27 CST