dweebd

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