Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: A searchable datastructure for represeting attributes?

Re: A searchable datastructure for represeting attributes?

From: Obnoxio The Clown <obnoxio_at_hotmail.com>
Date: Thu, 28 Feb 2002 20:38:49 GMT
Message-ID: <3c7e92b0.103562675@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:

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 - 14:38:49 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US