當我設計文檔時,我通常使用鏈接文檔來定義不同文檔類型之間的關係。設計鏈接對象
喜歡的東西:
EmailDocument
- 編號
- 主題
- UserLink
- 顯示名稱
- 用戶ID
用戶
- 編號
- 姓
- 名字
的問題是,如果用戶改變它的名字,舊名留在所有相關文件。鏈接文檔是不好的方法還是有更新所有這些鏈接的簡單方法? (我通常會創建一個名爲User
和一個叫UserLink
類。UserLink
包括在具有相對於用戶的所有其他文件。)
當我設計文檔時,我通常使用鏈接文檔來定義不同文檔類型之間的關係。設計鏈接對象
喜歡的東西:
EmailDocument
用戶
的問題是,如果用戶改變它的名字,舊名留在所有相關文件。鏈接文檔是不好的方法還是有更新所有這些鏈接的簡單方法? (我通常會創建一個名爲User
和一個叫UserLink
類。UserLink
包括在具有相對於用戶的所有其他文件。)
不,我不認爲這是一個不錯的辦法,因爲它會提高性能在許多情況下。但它確實增加了複雜性,並且需要您在父實體更改(用戶)時更新名稱的策略。
一個常見的設計是暴露事件 - 當引發事件「UserChangedName」時,您可以讓偵聽器更新所有EmailDocument實例中的所有DisplayName。
相關這裏後 - How to synchronize changes in nosql db (ravendb)
我只是存儲提供給特定用戶的引用EmailDocument內用戶ID字段。 Raven提供了一個包含函數,用於在當前會話/查詢中提取相關文檔,但沒有(或者至少非常少的 - Raven會被讀取優化)額外的成本和沒有額外的GET請求。
http://docs.ravendb.net/consumer/querying/handling-document-relationships.html
var email = session.Include<EmailDocument>(x => x.UserId)
.Load(id);
var user = session.Load<User>(email.UserId);
這將導致在這兩個文件翻出一個GET請求,你也有所有用戶文檔提供了更多的信息,你可以從兩個對象建立你的視圖模型。您還將消除必須跟蹤名稱更改並在發生這些更改時更新每個文檔的開銷。