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 saying that you would not remove both rows?
Thanks! On Thu, Nov 13, 2014 at 8:10 AM, Jonathan Vanasco <postg...@2xlp.com> wrote: > > 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 (user_id__a, user_id__b) > > if a relationship is confirmed (or dropped) I toggle is_reciprocal. > having that value saves a lot of work doing joins or analyzing friendship > sets > > if you have multiple relationship types, then things get tricky. > > you can either > - treat the row as a triplet ( user_id__a, user_id__b, > relationship_type_id) [i still recommend the reciprocal bool] > - if you have a finite set of relationship types, you could just > use each one as a bool column within the a2b row > > I've tried doing the "one row per relationship" approach, and didn't like > it. the time savings on simple searches were marginally faster, but the > sql was increasingly more complex and slower to execute as we leveraged the > table into other queries. > > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general >
