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:
- 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.
- 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).