Ral*_*cal 4 mongodb database-design database-recommendation relational-theory
我正在建立一个有用户的网站。用户可以搜索歌曲并(如果已登录)将它们保存到播放列表或歌曲库中。
我希望它像 iTunes 一样,播放列表上的所有歌曲都是库的一部分,所以当用户选择查看他们的歌曲库时,播放列表上的歌曲以及刚刚添加到库中的歌曲都会显示出来. 我想要一首歌能够存储在多个播放列表中。
现在我正在使用 Mongodb,做这样的事情:
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?)
});
Run Code Online (Sandbox Code Playgroud)
还有其他想法吗?
编辑:更多细节:
所以我拥有的是用户、库、播放列表和歌曲模型。
本质上,我正在尝试模拟 iTunes 之类的东西。
用户有一个库,该库属于该用户。一个用户可以有多个播放列表,播放列表属于该用户。一首歌曲可以在许多不同的用户库和属于不同用户或同一用户的许多不同播放列表中(甚至可能多次出现在同一个播放列表中?)。
当用户访问页面时,他们可以将歌曲添加到播放列表中,并且还会看到他们当前播放列表和音乐库的列表。如果他们单击播放列表,它将显示该播放列表中的所有歌曲,如果他们单击库,它将显示其库中的所有歌曲(例如 iTunes,所有播放列表中的所有歌曲和刚刚添加到库中的歌曲)。
不确定对此建模的最佳方法。
请注意那些发痒的downvote手指的人:我知道 OP 已经询问了 MongoDB,接下来的答案是 RDBMS。但是,如果您查看评论,您会发现我确实问过为什么 MongoDB 和 OP 的答案是基于性能的必要性假设。由于四天内没有人提出以 Mongo 为中心的答案,我将提出我的建议,即让 RDBMS 做它擅长的事情。
Raladical,正如我在对您的问题的评论中所指出的,我认为您尝试构建的内容非常适合关系数据模型。这是一个快速的数据模型草图:
该模型做出以下假设:
LIBRARY_ITEM
,PLAYLIST_ITEM
您可以在库和任何给定的播放列表中准确地播放一次或多次相同的歌曲。如果在您的应用程序中有意义,您还可以轻松扩展此模型以对 ARTIST 甚至位置等内容进行标准化。
这个模型是标准化的(3NF),如果你正确索引它,它将非常高效。如果您真的想要 MongoDB,或者您的系统还有其他非常适合非关系的东西,那么您绝对可以这样做。如果没有,您应该考虑使用 RDBMS。