处理Nosql（文档存储）中的共享对象
对于文档数据库，我不明白一件事，那就是如何处理共享对象。以这两个不同的对象/文档为例：
Email
BelongsTo (User object)
Comment
WrittenBy (User object)
两个文档中的用户是同一用户。
- 实际用户是否存储在文档或某种引用中（如在 RDBMS 中）
- 如何处理用户的更改（新的名字等）？
Theres one thing that I haven't understood with document databases and that's how to handle shared objects. Take this these two different objects/documents:
Email
BelongsTo (User object)
Comment
WrittenBy (User object)
The user is the same user in both documents.
- Are the actual user stored in the documents or some kind of reference (as in RDBMS)
- How are changes to the user handled (new first name etc)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这取决于您使用的 NoSQL 实现。您可以通过几种方式做到这一点：如果您使用 JCR（JackRabbit、CRX 等），您实际上可以存储对用户节点的引用，或者您可以采用关系方法并存储用户节点的地址。
It depends on the NoSQL implementation you use. You could do it a few ways: if you're using JCR (JackRabbit, CRX, etc) you could actually store a Reference to a user node, or you could go the relational approach and store a user node's address.
我想说这取决于您计划如何使用数据。例如，如果它是读取密集型的并且您只访问对象中用户的用户名，那么也许最好也在注释中复制该信息。如果您允许更改用户名，这当然会导致更高的更新成本，并且使用最新的用户名更新评论很重要。我们为读取模型使用了文档存储，并采用了复制数据的方式，因为我们为一个视图上下文构建了有效的视图/文档。当然，更新需要更多的资源，但对我们来说这没关系。我也一直在使用其他构造，根据 ids 在 doc1 和 doc2 之间使用“手动”引用。与 O/RM 相比，手动工作多一点，但魔法少得多。
BlogPost 有一个经典的例子 --<1:N>-- 评论，其中评论可以包含在我们可以通过 ID 访问的帖子中。再说一遍，你将如何使用它？您是否会在不显示帖子的情况下使用评论？您在看帖子时总是对评论感兴趣吗？ MongoDB 中 16MB 等文档大小的总存储是否存在潜在限制？那么你们可能需要分开。
我知道一个非常模糊的回答，但这也是一个非常“这取决于用例”的问题。
I would say it depends on how you are planning on consuming the data. E.g if it is read intensive and you only access username of the User in object, then perhaps it would be better to duplicate that info in comment as well. This would of course lead to higher update costs if you allow change of username and that it's important to have comments updated with the latest username. We have used document storage for our read-models and went the route with duplicating data, since we instead built effective views/documents made for one view-context. Sure the updates got more resource intensive, but for us that was ok. I've been working with the other construct as well, using "manual" references between doc1 and doc2 based on ids. A bit more manual work but much less magic than with O/RM's.
There's a classic example with BlogPost --<1:N>-- Comments, where the comments could be contained by the post our be accessed via a ID. Again, how will you use this? Will you ever use comments without also displaying the post? Are you always interested in the comments when looking at a post? Is there underlying limitations of total storage of a document size like 16MB in MongoDB? Then you might need to split apart.
I know a very vague response but it's also a very "it depends on the use case" question.