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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general