Isn't this typically handled with an inheritance (parent-children)
setup. MasterDocument has id, subtype and any common columns (create
date etc) then dependents use the same id from master to complete the
data for a given type. This is really common in ORM tools. Not clear
from the description if the operations could be similarly handled
(operation id, operation type as master of 17 dependent
operationSpecifics; there is also the "Activity Model")
I do that, but may be I do that badly.
Currently I do have 6 levels of inheritance which partition my
document-class space. But I cannot see any way to have a unique index
(unique constraint) to cover all those partitions at once.
This is actually the core of my question: How to make one?
I cannot image a single postgres index covering more than one physical
table. Are you really asking for that? Remember each dependent record
has an entry in the master so the master guarantees a unique set of keys
across all the dependents. Now if you have enough documents you may get
into partitioning but that's a separate issue.
How you model the work done on (or state transition of) those documents
is a yet another design, but at least the work flow model can safely,
consistently refer to the master table.
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
