Database-Design

希望對我應該如何建模這些數據提出一些建議

  • January 17, 2012

我正在建立一個有使用者的網站。使用者可以搜尋歌曲並(如果已登錄)將它們保存到播放列表或歌曲庫中。

我希望它像 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?)
});

還有其他想法嗎?

編輯:更多細節:

所以我擁有的是使用者、庫、播放列表和歌曲模型。

本質上,我正在嘗試為 iTunes 之類的東西建模。

使用者有一個圖書館,圖書館屬於該使用者。一個使用者可以有多個播放列表,並且播放列表屬於該使用者。一首歌可以在許多不同的使用者庫和屬於不同使用者或同一使用者的許多不同播放列表中(甚至可能多次在同一個播放列表中?)。

當使用者訪問頁面時,他們可以將歌曲添加到播放列表中,並且還會看到他們目前的播放列表和庫的列表。如果他們點擊播放列表,它將顯示該播放列表中的所有歌曲,如果他們點擊庫,它將顯示其庫中的所有歌曲(就像 iTunes 一樣,所有播放列表中的所有歌曲和剛剛添加到庫中的歌曲)。

不確定建模的最佳方法。

**請注意那些手指發癢的人:**我知道 OP 已經詢問了 MongoDB,接下來的答案是 RDBMS。但是,如果您查看評論,您會發現我確實問過為什麼 MongoDB 和 OP 的回答是出於性能的必要性假設。由於四天內沒有人提出以 Mongo 為中心的答案,我將提出我的建議,即讓 RDBMS 做它擅長的事情。


Raladical,正如我在對您的問題的評論中指出的那樣,我認為您正在嘗試建構的內容非常適合關係數據模型。這是一個快速的數據模型草圖:

數據模型草圖

該模型做出以下假設:

  • 使用者只能擁有一個庫。
  • 使用者可以有許多播放列表。
  • 歌曲可以出現在任意數量的播放列表中。
  • 如果歌曲已經在他們的庫中,使用者只能將歌曲放在播放列表中*(請注意,如果這不是您的意圖,有一個簡單的方法。)*
  • 根據您施加的限制LIBRARY_ITEMPLAYLIST_ITEM您可以在庫和任何給定的播放列表中恰好一次或多次播放同一首歌曲。

如果這在您的應用程序中有意義,您還可以輕鬆地擴展此模型以規範化 ARTIST 甚至位置等內容。

這個模型是標準化的(3NF),如果你正確地索引它,它會非常高效。如果你真的想要 MongoDB,或者如果你的系統有其他東西非常適合非關係,那麼你絕對可以這樣做。如果沒有,您應該為此考慮 RDBMS。

引用自:https://dba.stackexchange.com/questions/10654