2
嗨我已經開始在一個小型家庭項目上學習Mongo，以確定它是否可行作爲我們的一個產品在工作中的解決方案。在踏上我夢寐以求的道路之前，我想通過堆棧溢出來運行這個結構，以確定這個結構是否健全，並且可以在現在幾年內有效地訪問數據。設計一個具有多對多關係的mongodb模式
該應用程序爲足球遊戲收集傳播並允許用戶進行模擬投注。這就爲各種有趣的分析上下行的門博彩模式如何隨時間而改變傳播等
- 用戶
- 投注[]
- 隊
- 積分榜[]
- 遊戲
- 客隊{}
- 主隊{}
- 投注[]
你會從上面的列表我已經列出兩次下注通知。這是我的一個重要問題。將用戶存儲遊戲的文檔存儲在哪裏？在遊戲或用戶集合中。兩者都很有意義。如果我將其存儲爲一個而不是另一個，則必須查詢另一個列表中的大表來顯示數據。例如，如果我有users.bets，那麼當我想要顯示給定遊戲的所有投注時，我必須在所有users.bets中查找該game.id，反之亦然。這是否有效？理智？
我想這對我來說是一個掙扎。我知道如何處理關係數據庫中的多對多，但不在這裏。是第三個存儲多對多仍然是mongo的途徑。
歡迎您提出意見和參考資料。
MongoDb文檔很好地涵蓋了這些主題。 http://docs.mongodb.org/manual/data-modeling/正確的選擇主要取決於你想寫的查詢類型。你應該弄清楚具體是什麼。 MongoDb可能不太適合。 – WiredPrairie
通常在使用mongodb模式設計時，最重要的關注點是讀取效率，同時保持寫入的合理效率和原子性。有時這意味着嵌入，有時候會重複。還有未綁定收藏的問題;如果一個數組可能會隨意增長，它不適合嵌入。國際海事組織，在這裏，我會帶着一個單獨的賭注文件參考用戶+遊戲。投注可能與數據無關，足以保證他們自己的收藏，而且這是可擴展的，並且易於被用戶和/或遊戲查詢。 – numbers1311407
@WiredPrairie謝謝。我知道這可能不是最好的，這點就是學習mongo，並且樂在其中。 – systematical