W dniu 14.09.2017 o 23:15, Rob Sargent pisze: > > > On 09/14/2017 02:39 PM, Rafal Pietrak wrote: >> >> W dniu 14.09.2017 o 19:30, Rob Sargent pisze: >>> >>> On 09/14/2017 11:11 AM, Rafal Pietrak wrote: [------------------] >> >> Throwing actual numbers: 12 basic classes of documents; 17 tables >> registering various operations document may undergo during its lifetime. >> Variant (2) above make it 12*17 = 204 tables, which I'm currently >> maintaining.... and it's too much. With variant (1) I simply wasn't able >> to effectively keep document attributes consistent. >> >> Thus I'm searching for tools (paradigms/sql-idioms) that would fit the >> problem. > > 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? So far I only have separate unique indexes on all those 12 child-table document-class subtables. Is there a way to combine those indexes? I experimented, and an index created on parent table does not cover content of child/inheriting tables. If it was, that would solve the problem. .... or I've just missinterpreted you MasterDocument suggestion? -R -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
