幫助搜索內部文檔的架構設計

我正在尋找關於如何繼續處理MongoDB設計問題的建議。我有一個包含內部文檔的用戶文檔。幫助搜索內部文檔的架構設計

public class User 
{ 
    public ObjectId Id {get;set;} 
    public string UserName {get;set;} 
    public List<Skills> SkillLists{get;set;} 
    public string xxxx {get;set;} 
    public string yyyy {get;set;} 
    public string zzzzz {get;set;} 
} 

public class UserSkills 
{ 
    public ObjectId Id {get;set;} 
    public ObjectId UserId {get;set;} // contains reference to UserId 
    public string UserName {get;set;} 
    public List<string> Skills {get;set;} This is just an array of strings to help me search 
}

我保留一個單獨的集合以幫助我搜索具有特定技能的用戶。我的問題是，由於我的應用程序有能力讓用戶更改用戶名，我是否需要使用新用戶名更新所有UserSkills記錄？

我沒有設計架構的權利？

來源

2013-12-13 user636525

從外觀上看，你正在努力將SQL結構像MongoDB一樣強大。對於一對多的關係

的MongoDB/NoSQL的標準模型是通過嵌入子文件 http://docs.mongodb.org/manual/tutorial/model-embedded-one-to-many-relationships-between-documents/

如何在應用程序中創建類是你的，但映射到存儲層可能是希望用戶能夠看像這樣：

您可能需要的文件，看起來像這樣：

{ 
    _id: "...", 
    UserName: "Joe Bookreader", 
    Skill: [ 
      { 
       Name: "Microsoft Word", 
       level: "Expert 
      }, 
      { 
       Name: "Linux", 
       level: "Novice" 
      }, 
      ], 
    xxxx: "", 
    yyyy: "", 
    zzzz: "" 
}

然後

db.users.find（{ 「Skill.Name」：「Microsoft Word中」}）

返回整個文檔。

這樣更改用戶名有技能的名單上沒有影響

來源

2013-12-13 16:23:47

謝謝，如果用戶有教育的名單，然後將進入用戶的文件嗎？我在單獨的文檔中設計的原因是因爲我在某處讀到，不斷更新/刪除「文檔」並不是一個好主意。人們可以定期更新他們的技能，教育和其他「屬性」。你看到這個問題嗎？ – user636525

只有您可以說出您的性能瓶頸，並且您在更新大文檔時會有輕微的性能損失。底層表示（BSON）是不可變的，因此更新實際上是插入新文檔和刪除舊文檔。我沒有看到任何理由，你提出的想法會涉及沉重的IO，除非你有100k +以上的用戶非常頻繁地更新數據。作爲參考，我有一個非常類似的模式，但約有50個鍵，到目前爲止你有6個鍵。它在每秒執行〜5次更新的商品硬件上表現良好。 –

感謝您的解釋。 – user636525

匆匆一瞥，看起來好像沒有必要在UserSkills集合中嵌入UserID和UserName字段。從邏輯上看，技能並不一定是個人獨有的。用戶可能具有多種技能，並且多個用戶可能具有相同的技能，因此使得該技能的UserID或UserName和屬性是沒有意義的。

您可能最好擁有兩個集合Users和Skills並在用戶文檔中嵌套對技能的引用。您可以在Users.Skills子文檔中爲索引編制索引，以使搜索更容易。

來源

2013-12-13 16:14:29 woemler

幫助搜索內部文檔的架構設計

回答

相關問題