Thanks Jonathan. So in your use case would you put non-approved friend
requests in this table as non-reciprocal? If so, did the person requesting
friendship get the row in there or the person receiving the friend request?
Also, if A and B are friends, and B decided to remove A as a friend, are
you
Robert DiFalco wrote:
I have a question about modeling a mutual relationship. It seems basic but
I can't decide, maybe it is 6 of one a half dozen of the other.
In my system any user might be friends with another user, that means they
have a reciprocal friend relationship.
It seems I have
On Nov 11, 2014, at 5:38 PM, Robert DiFalco wrote:
Thoughts? Do I just choose one or is there a clear winner? TIA!
I prefer this model
user_id__a INT NOT NULL REFERENCES user(id),
user_id__b INT NOT NULL REFERENCES user(id),
is_reciprocal BOOLEAN
primary key
I have a question about modeling a mutual relationship. It seems basic but
I can't decide, maybe it is 6 of one a half dozen of the other.
In my system any user might be friends with another user, that means they
have a reciprocal friend relationship.
It seems I have two choices for modeling it.
On 11/11/2014 03:38 PM, Robert DiFalco wrote:
I have a question about modeling a mutual relationship. It seems basic
but I can't decide, maybe it is 6 of one a half dozen of the other.
In my system any user might be friends with another user, that means
they have a reciprocal friend
On 11/11/2014 02:38 PM, Robert DiFalco wrote:
I have a question about modeling a mutual relationship. It seems basic
but I can't decide, maybe it is 6 of one a half dozen of the other.
In my system any user might be friends with another user, that means
they have a reciprocal friend
On Tue, 11 Nov 2014 14:38:16 -0800
Robert DiFalco robert.difa...@gmail.com wrote:
I have a question about modeling a mutual relationship. It seems basic but
I can't decide, maybe it is 6 of one a half dozen of the other.
In my system any user might be friends with another user, that means
a difficulty of the single entry for joe-bob is that its hard to have
a unique constraint across two fields. you'd want to ensure that
joe+bob is unique and that there's no bob+joe
--
john r pierce 37N 122W
somewhere on the middle of the left coast
John R Pierce wrote
a difficulty of the single entry for joe-bob is that its hard to have
a unique constraint across two fields. you'd want to ensure that
joe+bob is unique and that there's no bob+joe
Bill's solution:
PRIMARY KEY (person1, person2),
CHECK (person1 person2)
seems
On 11/11/2014 5:32 PM, David G Johnston wrote:
Bill's solution:
PRIMARY KEY (person1, person2),
CHECK (person1 person2)
seems to make this constraint fairly simple...am I missing something?
oh, I guess I missed that part. of course, you'll have to make sure
you swap any relation into
10 matches
Mail list logo
