pg.ddx.io pgsql-sql@postgresql.org mailing list archive
help / color / mirror / Atom feedRe: Storing properties in a logical way.
3+ messages / 2 participants
[nested] [flat]
* Storing properties in a logical way.
@ 2004-09-06 03:42 Daniel M. <xt@nm.ru>
2004-09-05 17:51 ` Re: Storing properties in a logical way. Pierre-Frédéric Caillaud <lists@boutiquenumerique.com>
0 siblings, 1 reply; 3+ messages in thread
From: Daniel M. @ 2004-09-06 03:42 UTC (permalink / raw)
To: pgsql-sql
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?
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Storing properties in a logical way.
2004-09-06 03:42 Storing properties in a logical way. Daniel M. <xt@nm.ru>
@ 2004-09-05 17:51 ` Pierre-Frédéric Caillaud <lists@boutiquenumerique.com>
2004-09-06 19:37 ` Re: Storing properties in a logical way. Daniel M. <xt@nm.ru>
0 siblings, 1 reply; 3+ messages in thread
From: Pierre-Frédéric Caillaud @ 2004-09-05 17:51 UTC (permalink / raw)
To: pgsql-sql
> 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.
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Storing properties in a logical way.
2004-09-06 03:42 Storing properties in a logical way. Daniel M. <xt@nm.ru>
2004-09-05 17:51 ` Re: Storing properties in a logical way. Pierre-Frédéric Caillaud <lists@boutiquenumerique.com>
@ 2004-09-06 19:37 ` Daniel M. <xt@nm.ru>
0 siblings, 0 replies; 3+ messages in thread
From: Daniel M. @ 2004-09-06 19:37 UTC (permalink / raw)
To: pgsql-sql
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. 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 ?
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.
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2004-09-06 19:37 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2004-09-06 03:42 Storing properties in a logical way. Daniel M. <xt@nm.ru>
2004-09-05 17:51 ` Pierre-Frédéric Caillaud <lists@boutiquenumerique.com>
2004-09-06 19:37 ` Daniel M. <xt@nm.ru>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox