Thread: Storing properties in a logical way.

Hello everybody,

In a database there is a table with items, and each item can have
0 to n properties. The objective is to store information about items'
properties in a mentioned database in a logical and an efficient way.

Usually it is easily done by creating a validation table with a list
of possible properties and then creating a n-to-n relationship by means
of a linking table (hope I use the correct terms here).

But after looking closely at the list of a possible properties, i found
out that some of them depend on others. For example, if item is a
PDF document, it can have an index. But a document can also have an
index with links. Logically, a properties like 'index with links'
don't belong to the verification table - they look like a kind of
a composite field - 'index with links' is not a stand-alone property,
but it also implies that an item also has an 'index' property.
On the other hand, it is impossible to decouple 'index' from
'with links', because the second part won't have any meaning without
the first part.


How can such a kind of data be modeled in a logical way?

> But after looking closely at the list of a possible properties, i found
> out that some of them depend on others. For example, if item is a
> PDF document, it can have an index. But a document can also have an
> index with links. Logically, a properties like 'index with links'
> don't belong to the verification table - they look like a kind of
> a composite field - 'index with links' is not a stand-alone property,
> but it also implies that an item also has an 'index' property.
> On the other hand, it is impossible to decouple 'index' from
> 'with links', because the second part won't have any meaning without
> the first part.
You mean your properties would be better organized as a tree ?Or is it even more complicated than that ?
If it's a tree, look at the ways of storing a tree in a table.

On Sun, 05 Sep 2004 19:51:44 +0200, Pierre-Frédéric Caillaud 
<lists@boutiquenumerique.com> wrote:
>> But after looking closely at the list of a possible properties, i found>> out that some of them depend on others.
Forexample, if item is a>> PDF document, it can have an index. But a document can also have an>> index with links.
Logically,a properties like 'index with links'>> don't belong to the verification table - they look like a kind of>> a
compositefield - 'index with links' is not a stand-alone property,>> but it also implies that an item also has an
'index'property.>> On the other hand, it is impossible to decouple 'index' from>> 'with links', because the second part
won'thave any meaning without>> the first part.>>    You mean your properties would be better organized as a tree ?>
Oris it even more complicated than that ?
 

I never thought about that possibility - it is an interesting idea,
and it solves the logical problem (though there is still a need to
ensure that if child property is set, that the user won't be able
to also set a parent property - which is probably implementable by
using triggers).

Though I would prefer, if it is possible, something much simpler,
because there are only about 10 properties and 2 'composite'
properties - it would probably be an overkill to create a tree for
such a small table if a simpler solution exists.

Daniel.