Question

I’m looking for some db design help. I have an existing application that I’d like to add the following features to:

• Support the concept of a Site Blog
• Allow members to each have their own blog
• Admins can post to the Site Blog,
• Members can post to their own member blog

Since a Site can only have one blog, and each member can only have one blog. I don’t think I need a Blog table. Instead I’ll just hang a couple of columns off the Sites and Users tables for blog_name, blog_tagline, or something.

My question is: Should I use one table for posts or should I use 2 tables (site_posts and member_posts) instead.

If I use 1 table, I can easily have a type column (Site or Member) and a content_id column pointing to related parent record (site or member). But, I’m thinking what is the best way to do this in terms of resources and controllers. If I have 1 table then I’d have one controller Posts. But, based on a user’s role they’d be updating either Site posts or Members posts. This seems a little messy, always checking a user’s role just to update a resource.

So, I’m leaning towards 2 resources (and 2 tables), so I know that Members are always working on member_posts and admins on site_posts.

Anyone have any thoughts on this design or see any issues?

Thanks.

Answer 1

You might consider one table (posts), but two subclasses (SitePost and MemberPost) that inherit from it.
This allows you to put most of the functionality into the post Model.

You can even put most of the controller functionality into the PostsController

You can then have two subclass controllers for SitePostController and MemberPostController – that inherit from PostController… but have different before_filters for the specific requirements for resource security.

…In fact, you may even be able to get away with a single PostsController and have each of the two subclasses have their own “can_be_edited_by?” method… which is called in the before_filter for the member-methods of your post. Just make sure the post is instantiated to the correct type – which may require some routing magic to ass in the “post_type” to your controller. eg:

class Post < ActiveRecord::Base
   ...post-specific methods
end
class MemberPost < Post
  def can_be_edited_by?(user)
    ... MemberPost-specific authorisation
  end
end
class SitePost < Post
  def can_be_edited_by?(user)
    ... SitePost-specific authorisation
  end
end

class PostsController <...
  before_filter :requires_login
  before_filter :fetch_post, :only => [:edit, :update, :delete, :show]
  before_filter :can_edit_post, :only => [:edit, :update, :delete, :show]

  ...
  def can_edit_post
    @post.can_be_edited_by?(current_user)
  end
  def fetch_post
    post_class = (params[:post_type] || 'SitePost').constantize
    @post = post_class.find(params[:id])
  end

end

Routing magic (and any bugs) left as an exercise for the reader 😉