| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Rafal Pietrak <rafal(at)ztk-rp(dot)eu> |
| Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: multiple UNIQUE indices for FK |
| Date: | 2016-02-28 02:35:44 |
| Message-ID: | CAKFQuwZ1rDPjEv2tAs9QRigUpea8J16AacXmNbxtQJR319SqEg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
>
> W dniu 23.02.2016 o 09:39, Rafal Pietrak pisze:
> > Can anybody suggest any other way out of this mass?
>
The only thought that sticks while reading your prose is:
message ----> message-person <---- person
message-person (message_id, person_id, relationship_type[sender, receiver])
Partitioning and partial indexes both have considerable limitations that
you might need to work around. That said normalization exists for a reason
and having multiple "person" columns in a table is a form of duplication
that if left presents just the problems you are seeing.
I suspect your SSN should fit onto the message-person table.
The following doesn't make sense - if the SSN is sender unique then there
is no expectation that a receiver would not receive two messages with the
same SSN from different senders.
ALTER ... msgs_to_me ADD CONSTRINT them_uniq UNIQUE (THEM,SSN);
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Aaron Christensen | 2016-02-28 05:19:29 | Re: Designing tables based on user input and defined values |
| Previous Message | Adrian Klaver | 2016-02-28 00:03:11 | Re: Designing tables based on user input and defined values |