1

I'm building a streaming music service that will have features like:

  • Follow users
  • Like songs
  • Create and manage playlists
  • ...etc.

I'm using Rails 3.1, Mongoid and MongoDB. I'm unsure how I should model my User, Playlist and Song models.

There is a many to many relationship between playlists and songs. Mongoid is storing ObjectId's of each song in an array of each playlist. But I need to add some metadata to each song <-> playlist relationship, like the position of the song in the specific playlist.

I'm also unsure of how to do things like finding out which mutual friends and mutual likes a user has with another user. Is is really a good idea to store a users likes and friends inside the user document? A user could possibly have several thousand likes and over a thousand friends etc.

Is this kind of stuff better suited for a relational database?

Johan
  • 1,897
  • 5
  • 23
  • 29
  • This answer has a good discussion on modeling likes: http://stackoverflow.com/questions/28006521/how-to-model-a-likes-voting-system-with-mongodb – Michael Cole Jun 11 '15 at 14:07

2 Answers2

1

I know this question is old, but its worth having answers on here that other people can read.

Mongo was built for concepts such as likes. The document store makes is very easy to add features such as this without having to ditch your model, data or do any migration.

NoSQL dbs (and mongo is not the fastest) are lightening quick so you can take advantage of this and make your model simple.

I would create documents called Songs, Users, Likes & Playlists, and then create associations between them. You can change the logic to suit your case, but if you assume that a Playlist is shared between users but owned by one user you would create the following associations (depending on the mongo driver the syntax will be different, below is mongomapper):

 Playlists: 

 many :users, :as => :shared_with_users
 one :users, :as => :owner

 Users:

 many Playlists

This will create associations between the objects. Under your User object you will be able to find the playlists associated by that user using user.playlist which will return a cursor of the playlist objects associated. The same as if you are using the playlist object you can look at the owners or the shared_with_users to find the objects you want that way.

ABrowne
  • 1,574
  • 1
  • 11
  • 21
0

The question you should ask yourself in the first place is : Why do I want to use mongoDB for this application ?

Your need seems well-fitted for relationnal database world (= complex relationship between objects). So maybe you will be happier with a relationnal database.

There are many options to your problem (each of them have trade-offs of course) :

  • you can store you M2M relation in a separate collection and do some client-side joint
  • you can embed songs into playlist, or playlist into songs
  • you can store some of your playlist (the most used for instance) into the songs and client-side join with another collection for the least used playlist
  • you can also store some information regarding playlist in your songs and the rest in an independant collection.
  • ...

Your options are quite unlimited, you have to precise your needs to be able to make a good choice.

If you are just building you application, start with somehting very simple (maybe client side joint is easy even if it requires more requests) and then start improving your model depending what your bottlenecks are.

kamaradclimber
  • 2,479
  • 1
  • 26
  • 45
  • I'm quite happy using MongoDB. I could convert everything to a relational database, but I mean, even if I do client-side joins with two queries instead of one, how much slower would that be if it's indexed properly? I was looking for best practices for my situation ... :) – Johan Oct 18 '11 at 15:39
  • it would 2 times slower and I think it would depends more on the latency speed of you network than the query speed (if correctly indexed of course) – kamaradclimber Oct 19 '11 at 06:09