2014-02-17 48 views
0

我試圖用Node.JS和MongoDB構建面向媒體的API。該應用程序的主要部分是媒體實體。您可以與用戶,事件等共享的媒體實體架構如下:MongoDB數據庫模式設計建議(共享)

created: 'Jan 12 2014', 
    title: 'New Book', 
    description: 'This is a new book', 
    fileType: 1, 
    size: 230, 
    categories: ['horror', 'romantic'], 
    tags: ['drama', 'new'], 
    events: ['123', '234'], 
    users: ['111', '222'], 
    type: 1, 
    creator: 'John Gallagher', 
    uri: 'http://test.com/book.pdf' 

我試圖做到的,是查詢以下操作的簡單方法:

操作:

  • 媒體A與用戶B共享的,C
  • 媒體A被事件d內加入,E

查詢:

  • 顯示了與用戶B共享

    db.media.find所有媒體({用戶: '111'})

  • 顯示事件d

    之內的所有媒體

    db.media.find({事件: '234'})

我不知道如何approa這個問題。這對於既定目標是否合理?

+2

看起來沒給我,只要股和事件集合不太大,超出最大文件尺寸。 –

+0

@JoachimIsaksson什麼是避免這種情況的更好方法? – litenull

回答

1

正如已經談到,有什麼不對這種類型的模式爲你建議做的操作,到目前爲止,就像你如何解釋自己這一點。還有人提到你這裏唯一真正的約束是你希望在這些數組中保留多少項,這對文檔大小有影響。還有一點,數組中太多的項會導致某些操作的性能顯着降低。

但是,如果每個文檔的尺寸將是比較小的,那麼所有應該沒問題。

幾個疑難雜症點未啓動:

既然你有幾個數組元素的結構,你會發現自己想上的兩個或多個元素的組合來篩選結果。它是那麼值得一讀在這種情況下,對多鍵索引limitations部分,並瞭解各種查詢的作用以及如何構建你的索引。總之,每個複合指數只有一個Multikey索引字段,作爲包含多個的排列的限制。

如果您的嵌入式陣列看起來像增加了超過合理數量的元素,那麼值得看看關於「storing comments」用例的文檔。這包括少數情況下,併爲一些協會有一個Hybrid Schema一節,其中討論了被稱爲「桶裝」,可能會對你有幫助的技術。