| From: | "Daniel M(dot)" <xt(at)nm(dot)ru> | 
|---|---|
| To: | pgsql-sql(at)postgresql(dot)org | 
| Subject: | Re: Storing properties in a logical way. | 
| Date: | 2004-09-06 19:37:27 | 
| Message-ID: | 413CBC77.7060806@nm.ru | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-sql | 
On Sun, 05 Sep 2004 19:51:44 +0200, Pierre-Frédéric Caillaud 
<lists(at)boutiquenumerique(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Troels Arvin | 2004-09-06 20:30:24 | When a table was last ANALYZEd | 
| Previous Message | Andrei Bintintan | 2004-09-06 14:03:02 | How to rename a constraint/trigger?? |