It is frequently desirable to represent bidirectional relationships in web applications, and simple databases are not immediately suitable for this information.
Let’s start with a simple unidirectional example that a database like MySQL handles well.
User 1 wants to be friends with User 2.
A row is inserted into the befriendings table with User 1 as the initiator and User 2 as the recipient.
Now, if your friendships are unidirectional the job is pretty much done. If User 2 wants to be friends with User 1, they can initiate a befriending of their own. On Kongregate, users you have befriended are called “Friends”, and users who have befriended you are called “Fans”
class User < ActiveRecord::Base
has_many :initiated_befriendings,
:class_name => :Befriending, :foreign_key => :initiator_id
has_many :received_befriendings,
:class_name => :Befriending, :foreign_key => :recipient_id
has_many :friends, :through => :initiated_befriendings,
:source => :recipient
has_many :fans, :through => :initiated_befriendings,
:source => :initiator
end
However, sometimes you want to follow a friendship model more like the one used by Facebook or MySpace, where all friendships are bidirectional.
Both of these sites implement a relationship-confirmation step before any relationship is finalized. For simplicity’s sake, I’ll skip over modeling that step, but suffice it to say, pending relationships are best stored separately from confirmed relationships. Attempting to mix the two needlessly mingles data and complicates application logic.
Let’s assume any user has the ability to initiate the bidirectional relationship. Now, in the befriendings table, we technically have all the information necessary to list all friends of User 1, and all friends of User 2.
SELECT * FROM befriendings WHERE initiator_id = 1 OR recipient_id = 1 ORDER BY created_at;
SELECT * FROM befriendings WHERE initiator_id = 1
UNION SELECT * FROM befriendings WHERE recipient_id = 1 ORDER BY created_at;
In the first case, only one index can be used (on either initiatior_id, or on recipient_id), and in both cases, the ORDER clause necessitates a filesort on the results.
So the simplest approach here would be to simply duplicate the relationship data in another row, swapping the initiator and recipient ids. This is okay, but starts to fall apart as store more information about the relationship itself. For example, imagine we store a compatibility score between the two users, as last.fm does.
This information would need to be duplicated, as well as keeping the the various timestamps in-sync. Indices against these fields would bloat unnecessarily.
Instead, we can move the duplicated information to a dedicated table, eliminating indices on the relationships table itself. The column by which results are ordered is moved from the relationships table to the dedicated table.
class Befriending < ActiveRecord::Base
belongs_to :initiator, :class_name => :User
belongs_to :recipient, :class_name => :User
after_create do |b|
BefriendingEdge.create!(:user => b.initiator, :befriending => b)
BefriendingEdge.create!(:user => b.recipient, :befriending => b)
end
end
class BefriendingEdge < ActiveRecord::Base
belongs_to :user
belongs_to :befriending
end
Users then access their list of friends through a :friends association and can access the rich information about the relationship itself through the :befriendings association. The befriending_edges table’s indices are simple and very efficient, and looking up befriendings uses a single primary key, and looking up friends uses two primary keys.
class User < ActiveRecord::Base
has_many :befriending_edges
has_many :friends, :through => :befriending_edges, :source => :user
has_many :befriendings, :through => :befriending_edges, :source => :befriending
end
