Question

I am creating a system where I have something like a “manual recommendation system”. It works like this: if a user thinks something inside the system is interesting, it can “recommend” this content. This content will then be recommended to all the user’s followers (they will appear in their “wall”). (I don’t care about who visited or any kind of automation, for me it is only important that the user is able to share comments by clicking in a button).

Let’s say a user I follow recommends a blog post, a link to this post will appear in my “wall”. This link contains the post title, description and so on.
He could also recommend videos, photos and users profiles and so on.

For each kind of content which is recommended, I will have a different layout and different information will be displayed, and here is where my problem lies:

I am having some issues creating the approach so solve this problem: How can I keep track of what was recommended, keep the information updated (if the post title was changed, it should change in the recommendation) and keep my solution clean?

These are the approaches I’ve though and the reasons I don’t like them:

• Create a “general” table, called Recommendation. This would have recommendation title, recommendationInfo_1, recommendationInfo_2, recommendationInfo_3,…, recommendationInfo_N.
  This is a nice approach because it would be easy to retrieve and all recommendation types would be able to use the same columns.
  I didn’t like it because it doesn’t keep the information updated (it is somehow complex to do that, I would have to check for possible recommendations every time an object is updated) and it looks messy.

• Create a recommendation table and a “value pair table”. The recommendation table would have the fields which are common to all of the recommendation types, and the key value table would have specific information for each recommendation type.
  I didn’t like it because it has the same problems maintaining the fields updated, this second table looks messy for me, and it would not be as simple to perform queries to retrieve all kinds of recommendations at once.

• Create a recommendation table which contains only the recommendation ID, recommendation Type and content id. The table looks cleaner, which is a plus point, and it also solves the updated information issue.
  The problem here is: I’m afraid the retrieval query will be very complex, I will have to perform N “outer join”, being N the number of content types I have and my select clause can grow pretty fast due to the different kinds of information coming from different content types.

Do you have any ideas/articles/design patterns that could help me?

ps: I don’t know if this is important, but I’m using asp.net and msssql

Answer 1

So your users can recommend photos, videos, cars, bananas, etc. Make a table which has all these things listed. So all items that a user may recommend are in the Thing or Object table, with information on what kind of thing it is and where the additional information is.

When a user recommends a thing, you simply create a relation between the user and the thing. The Recommendation table would thus have userId, thingId and maybe a timestamp to indicate when the thing was recommended.

In your program, you would make a superclass Thing with subclasses Photo, Video, Car, Banana. Maybe all your things implement some interface, so that you can call thing.getName() no matter what kind of thing it is.