>> 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.
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
