Question

I’m building a site similar to Yelp (Recommendation Engine, on a smaller scale though), so there will be three main entities in the system: User, Place (includes businesses), and Event.

Now what I’m wondering about is how to store information such as photos, comments, and ‘compliments’ (similar to Facebook’s “Like”) for each of these type of entity, and also for each object they can be applied to (e.g. comment on a recommendation, photo, etc). Right now the way I was doing it was a single table for each i.e.

Photo (id, type, owner_id, is_main, etc…)
where type represents: 1=user, 2=place, 3=event

Comment (id, object_type, object_id, user_id, content, etc, etc…)
where object_type can be a few different objects like photos, recommendations, etc

Compliment (object_id, object_type, compliment_type, user_id)
where object_type can be a few different objects like photos, recommendations, etc

Activity (id, source, source_type, source_id, etc..) //for "activity feed"
where source_type is a user, place, or event

Notification (id, recipient, sender, activity_type, object_type, object_id, etc…)
where object_type & object_id will be used to provide a direct link to the object of the notification e.g. a user’s photo that was complimented

But after reading a few posts on SO, I realized I can’t maintain referential integrity with a foreign key since that’s requires a 1:1 relationship and my source_id/object_id fields can relate to an ID in more than one table. So I decided to go with the method of keeping the main entity, but then break it into subsets i.e.

User_Photo (photo_id, user_id) | Place_Photo(photo_id, place_id) | etc…

Photo_Comment (comment_id, photo_id) | Recommendation_Comment(comment_id, rec_id) | etc…

Compliment (id, …) //would need to add a surrogate key to Compliment table now

Photo_Compliment(compliment_id, photo_id) | Comment_Compliment(compliment_id, comment_id) | etc…

User_Activity(activity_id, user_id) | Place_Activity(activity_id, place_id) | etc…

I was thinking I could just create views joining each sub-table to the main table to get the results I want. Plus I’m thinking it would fit into my object models in Code Igniter as well.

The only table I think I could leave is the notifications table, since there are many object types (forum post, photo, recommendation, etc, etc), and this table will only hold notifications for a week anyway so any ref integrity issues shouldn’t be much of a problem (I think).

So am I going about this in a sensible way? Any performance, reliability, or other issues that I may have overlooked?

The only “problem” I can see is that I would end up with a lot of tables (as it is right now I have about 72, so I guess i would end up with a little under 90 tables after I add the extras), and that’s not an issue as far as I can tell.

Really grateful for any kind of feedback. Thanks in advance.

EDIT: Just to be clear, I’m not concerned if i end up with another 10 or so tables. From what I know, the number of tables isn’t too much of an issue (once they’re being used)… unless you had say 200 or so :/

Answer 1

If you rearrange things slightly, you can simplify your comments and compliments. Essentially you want to have a single store of comments and another one of compliments. Your problem is that this won’t let you use declarative referential integrity (foreign key constraints).

The way to solve this is to make sure that the objects that can attract comments and compliments are all logical sub-types of one supertype. From a logical perspective, it means you have an “THING_OF_INTEREST” entity (I’m not making a naming convention recommendation here!) and each of the various specific things which attract comments and compliments will be a sub-type of THING_OF_INTEREST. Therefore your comments table will have a “thing_of_interest_id” FK column and similarly for your compliments table. You will still have the sub-type tables, but they will have a 1:1 FK with THING_OF_INTEREST. In other words, THING_OF_INTEREST does the job of giving you a single primary key domain, whereas all of the sub-type tables contain the type-specific attributes. In this way, you can still use declarative referential integrity to enforce your comment and compliment relationships without having to have separate tables for different types of comments and compliments.

From a physical implementation perspective, the most important thing is that your various things of interest all share a common primary key domain. That’s what lets your comment table have a single FK value that can be easily joined with whatever that thing of interest happens to be.

Depending on how you go after your comments and recommendations, you probably will (but may not) need to physically implement THING_OF_INTEREST – which will have at least two attributes, the primary key (usually an int) plus a partitioning attribute that tells you which sub-type of thing it is.