Would appreciate some suggestions on how I should model this data

Question

I am setting up a website that will have users. Users can search for songs and (if signed in) save them to a playlist or their library of songs.

I want it to be like iTunes in that all the songs on the the playlists are part of the library so when the user choses to view their library of songs, the songs on the playlists are shown as well as the songs just added to the library. I'd like a song to be able to be stored in multiple playlists.

Right now I am using Mongodb, doing something like such:

var UserSchema = new Schema();

var Library = new Schema({
    songs: [SongsSchema],
    user: Schema.ObjectId
});

var Playlist = new Schema({
title: String,
description: String,
user: Schema.ObjectId   
});

var SongsSchema = new Schema({
position: Number,
name: String,
artist: String,
    artistGid: String,
album: String,
    albumGid: String
time: Number,
url: String,
    gid: String,
    location: String (either youtube, vimeo, soundcloud for now),
    playlist: [Schema.ObjectId] (array of object ids that point to playlists?)
});

Any other ideas?

edit: More details:

So what I have is a user, library, playlist, and song model.

Essentially I am trying to model something like iTunes.

A user has a library and the library belongs to that user. A user can have several playlists and the playlist belongs to the user. A song can be in many different user libraries and many different playlists that belong to different users or the same user (perhaps even on the same playlist multiple times?).

When a user visits a page they can add songs to a playlist and will also see a list of their current playlists and their library. If they click the playlist it will show all the songs on that playlist if they click library it will show all the songs in their library( so like iTunes all the songs on all the playlists and ones just added to the library).

Not sure of the best way to model this.

Answer 1

NOTE to people with itchy downvote fingers: I know that OP has asked about MongoDB and the answer that follows is RDBMS. However, if you check out the comments you'll see that I did ask why MongoDB and OP's answer is a presumption of necessity due to performance. Since nobody has come forth with a Mongo-centric answer in four days, I am going to offer my suggestion, which is to let RDBMS do what it's good at.

---

Raladical, as I noted in my comments to your question, I think that what you are trying to build is perfectly suited to the relational data model. Here is a quick data model sketch:

This model makes the following assumptions:

• Users can have exactly one library.
• Users can have many playlists.
• Songs can appear in any number of playlists.
• Users can only put songs in a playlist if it's already in their library (Note that there is an easy way around this if that is not your intention.)
• Depending on the constraints you put on LIBRARY_ITEM and PLAYLIST_ITEM you can have the same song exactly once or several times in both the library and any given playlist.

You can also easily extend this model to normalize for things like ARTIST and possibly even location, if that makes sense in your application.

This model is normalized (3NF) and if you index it properly it will be very performant. If you really want MongoDB or if there is something else about your system that is well suited to non-relational then you can definitely do it that way. If not, you should think about RDBMS for this one.