1

I'm currently writing an application using the MEAN stack, pretty much only for fun and because MEAN is "cool" at the moment.

Therefore I'm thinking about the database layout. The data needed to be saved represents a music collection. So I had two ideas. But because I'm quite new to NoSQL, I don't know which one I should use or if both of them are rubbish.

First idea:

One big collection "artists" with an array "albums". This array also has an array called "songs". Here I don't know what to do about playlists!

Second idea:

Four collections "artists", "albums" ,"songs" and "playlists" all linked using the _id field - This is how I would do it in a traditional database, like MySQL.

Which one would in your opinion fit better and - that's what I'm even more interested in - why?

  • What attributes are you going to record? For example, do you want to store the length of each song on an album? Do you want to store the members of the album's bands? – mdoyle Apr 9 '14 at 14:29
  • Also, ccould you clarify what you mean by "Here I don't know what to do about playlists"? Are you considering storing particular combinations of songs from different albums as though they were albums? – mdoyle Apr 9 '14 at 14:30
  • 1. I want to store meta information about songs, but not about albums. 2. I don't know "where" I should save them. – Martin Apr 9 '14 at 14:48
  • I'm still not clear on what you have in mind by "playlists". Is a playlist just the track listing of an album--the songs on it--or is it a selection of songs from various albums? – mdoyle Apr 9 '14 at 15:58
  • The last one. Just a selection of random songs from various albums and artists. – Martin Apr 9 '14 at 17:09
1

I think your first idea is better. The second way, as you state, is how you would model the data in an RDBMS. If you're going to use MongoDB for fun, you might as well explore the fact that it has a different data model, and structure your collections accordingly. While I'm sure performance is not going to be an issue for the scale of this project, keeping the data in a single document avoids joins, which can be expensive. It's commonly held that, within MongoDB environments, denormalization is faster (see here).

In the schema describe in your first idea, playlists could all be subdocuments in a kind of catch-all artist document called "various". I imagine the same would be done in a relational implementation, with the table artist having a record for "various", to cover compilation albums and soundtracks, for example.

I have a JSFiddle here with a JSON representation of what a music collection might look like implemented as your first idea.

Of course, there is yet another way, and that is a collection albums, with most documents having a key artist, which could either be a reference to the _id from a document in a collection artists, or just have the name of the artist itself. In this implementation, playlists wouldn't have this key; or, alternatively, it could be an array with all the artists with tracks in the playlist.

  • If you're going to downvote an answer, perhaps you could provide a comment as to why. It's helpful for improving answers in the future. – mdoyle Apr 9 '14 at 21:20
  • 1
    I haven't downvoted but "commonly held that denormalization is faster"? That's not entirely accurate. There are many who swear on normalization. – ypercubeᵀᴹ Apr 10 '14 at 17:31
  • 1
    @ypercube: Very true, that was sloppily written on my part. The source there is a MongoDB engineer, and he must be referring to MongoDB itself. The RDBMS world has had years to work on making joins fast, and has been successful at it. – mdoyle Apr 11 '14 at 14:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.