Question

I want to create a table where my users can associate a friendship between one another. Which at the same time this table will work in conjunction to what I would to be a one-to-many relation between various other tables I am attempting to work up.

Right now I am thinking of something like this

member_id, friend_id, active, date

member_id would be the column of the user making the call, friend_id would be the column of the friend they are attempting to tie to, active would be a toggle of sorts 0 = pending, 1 = active, date would just be a logged date of the last activity on that particular row.

Now my confusion is if I were to query I would typically query for member_id then base the rest of the query off of associated friend_id’s to display data accordingly to the right people. So with this logic of sorts in mind, that makes me think I would have to have 2 rows per request. One where its the member_id who’s requesting and the friend_id of the request inserted into the table, then one thats the opposite so I could query accordingly every time. So in essences its like double dipping for every one action requested to this particular table I need to make 2 like actions to make it work.
Which in all does not make sense to me as far as optimization goes. So in all my question is what is the proper way to handle data for relations like this? Or am I actually thinking sanely about this being an approach to handling it?

Answer 1

If a friendship is always mutual, then you can choose between data redundancy (i.e. both directions having a row) for the sake of simpler queries, or learn to live with slightly more complex queries. I’d personally avoid data redundancy unless there is a compelling reason otherwise – you’re not just wasting space and performance, but you’ll need to be careful when enforcing it – a simple CHECK is incapable of referencing other rows and depending on your DBMS a trigger may be limited in what it can do with a mutating table.

An easy way ensure to only one row per friendship is to always insert the lower value in member_id and higher value in friend_id (make a constraint CHECK (member_id < friend_id) to enforce it). Then, when you query, you’ll have search in both directions – for example, finding all friends of the given person (identified by person_id) would look something like this:

SELECT *
FROM
    person
WHERE
    id <> :person_id
    AND (
        id IN (
            SELECT friend_id
            FROM friendship
            WHERE member_id = :person_id
        )
        OR
        id IN (
            SELECT member_id
            FROM friendship
            WHERE friend_id = :person_id
        )
    )

BTW, in this scheme, you’d probably want to rename member_id and friend_id to, say, friend1_id and friend2_id…