|From:||Rafal Pietrak <rafal(at)ztk-rp(dot)eu>|
|Subject:||Re: looking for a globally unique row ID|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
> 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?
|Next Message||s19n||2017-09-15 10:25:58||"Canceling authentication due to timeout" with idle transaction and reindex|
|Previous Message||Michael Paquier||2017-09-15 06:55:02||Re: pg_rewind copy so much data|