1

I am building a social network, which will have standard features of 'likes' (upvotes) for posts, 'following' between users and 'stars' for favorite posts. These might reasonably expand in the future for similar functionality.

I am mostly using NoSQL (namely, MongoDB docs) but would appreciate an SQL perspective as well.

I am planning on persisting these in collections which might hold documents as following:

Followers Collection, example doc: {follower_id: 123, followee_id: 456}

Likes Collection, example doc: {liker_id: 123, post_id: 789}

Stars Collection, example doc: {user_id: 123, starred_item_id: 555}

The emerging structure seems very similar. Some additional data may be identical (creation date?), and while other might be different (type of item liked/starred/followed, and/or additional, type-specific fields [say a numerical value for a 'rating' class]), there appears to be so much in common that it might be prudent to consolidate all of these into a similar 'model', both in terms of a single DB collection (or SQL table) as well as shared/single code model.

I am mostly concerned about:

  1. Collection growing too large - this is already a concern just for 'likes', it might be exacerbated (although only by ~*3) by throwing in 'stars' and 'followers' too.
  2. Logic between these data objects growing apart over time, making using a shared data model wrong.

So, would this be a good idea? Likes/Stars/Following - are they more similar or more separate?

Most specifically, assuming 3 collections which are similar but not identical, would it make more sense to consolidate them into one or keep them separate? Both considering code complexity (and DRYness) and DB constraints (e.g. index size).

sellarafaeli
  • 119
  • 4
  • 2
    You have to decide what these things mean in your application. Likes are pretty straightforward: "I like this." Following is also pretty straightforward. You can like *and* follow a post; they are separate operations, and therefore deserve separate data structures. Stars are the ambiguous ones; do they mean "I like this," "I'm following this," or do they mean something else? – Robert Harvey Apr 09 '15 at 17:17
  • @RobertHarvey, even if separate operations, perhaps there is a benefit to storing them together due to their similarity? Suppose each row/document would have 'user_id', 'item_id', and 'action_type' (like/follow/star). Would a single table/collection be more/less efficient than multiple ones? – sellarafaeli Apr 10 '15 at 08:13
  • 1
    When I once wrote an office management system, I had an "events" table that carried basic information about todos, appointments and projects. But that was for notification purposes only; the notification system had to know about all three of these entities, so there were joins to todo, appointment and project records from the events table. This allowed notification for all such entities to derive from a single source. – Robert Harvey Apr 10 '15 at 14:07
  • aside: Why aren't these "Collections" json arrays? You made them json objects. – Daniel Kaplan Apr 10 '15 at 18:03
  • @DanielKaplan - explain? These are collections of JSON documents. In each case I gave an example of what one doc might look like. – sellarafaeli Apr 12 '15 at 09:02

1 Answers1

0

Since Likes and Stars(favorite) pertain to the same object, a "post". A unifying domain could be used to store Likes and Stars such as postIcons: {userId: '123', postId:'789', like: true, star: true}. You would have an entry for every post your user liked or favorited but would only have one record for a post your user liked and favorited.

'Followee' pertains to another user. So your user can follow many other users. Sounds like Follows could be a List of ids on a user object such that your user has many 'followeeIds'.

In your comment where you have an 'action_type' you would have a record for the same user and the same item for each 'action_type'.

dspano
  • 109
  • 3