为对象MongoDB的关系 [英] MongoDB relationships for objects

问题描述

请原谅我的英语，我还在努力掌握它。

Please excuse my english, I'm still trying to master it.

我已经开始学习MongoDB中（从C＃背景的），我喜欢什么是MongoDB的想法。我有一个在互联网上的例子一些问题。

I've started to learn MongoDB (coming from a C# background) and I like the idea of what is MongoDB. I have some issues with examples on the internet.

以流行的博客文章/评论的例子。邮政有没有或与之相关的许多评论。我创建Post对象，添加一些评论的对象到IList中邮中。 。那细

Take the popular blog post / comments example. Post has none or many Comments associated with it. I create Post object, add a few Comment objects to the IList in Post. Thats fine.

我补充一点，只是一个信息收集MonoDB或者我应该有两个集合 - 一个是blog.posts和blog.posts.comments？

Do I add that to just a "Posts" Collection in MonoDB or should I have two collections - one is blog.posts and blog.posts.comments?

我有一个公平的复杂的对象模型，想起来最简单的方法是银行系统 - 我们是采矿。有我试图强调用方括号表。

I have a fair complicated object model, easiest way to think of it is as a Banking System - ours is mining. I tried to highlight tables with square brackets.

[用户] 有一个或多个的 [帐户] 一个或多个的 [交易] 有且只有一个【型号】。 [交易] 可以有一个或一个以上的 [标签] 分配给交易。 [用户] 创建自己的 [标签] 独有的用户帐户，我们有时需要通过这些标签提供的报告（如五月，标签钻井费用为$ 123456.78 ）。

[Users] have one or many [Accounts] that have one or many [Transactions] which has one and only one [Type]. [Transactions] can have one or more [Tag] assigned to the transaction. [Users] create their own [Tags] unique to that user account and we sometimes need to offer reporting by those tags (Eg. for May, tag drilling-expense was $123456.78).

有关索引，我还以为他们分隔条件将是一件好事，但我很担心，这是不好的做法，从旧RBDMS天这种想法。

For indexing, I would have thought seperating them would be good but I'm worried it is bad practice this thinking from old RBDMS days.

在某种程度上，它像博客的例子。我不知道我是否应该有1 [帐户] 收集和持续存在的所有信息，或有分裂之达到单独收集的中间步骤。

In a way, its like the blog example. I'm not sure if I should have 1 [Account] Collection and persist all information there, or have an intermediate step that splits it up to seperate collections.

其他相关查询，当你坚持来回，你通常会得到回来的所有的与该记录相关联 - 即使不是必需的，或你限制

The other related query is, when you persist back and forth, do you usually get back everything associated with that record - even if not required or do you limit?

推荐答案

这要看情况。

这取决于你希望有多少这些类型的对象的拥有。你能适应他们都到一个单一的MongoDB文档，交给用户？ 。也许不是

It depends on how many of each of these type of objects you expect to have. Can you fit them all into a single MongoDB document for a given User? Probably not.

这取决于关系 - 是用户账户一到一对多或多对一一对多的关系？如果是一对多和账户数量很少，你可能会选择将它们放在一个IList上的用户文档。

It depends on the relationships - is user-Account a one-to-many or a many-to-many relationship? If it's one to many and the number of Accounts is small you might chose to put them in an IList on a User document.

您可以在MongoDB中仍然模型关系有独立藏品但在数据库中没有连接，所以你必须做的，在代码。加载用户，然后装入自己的账户可能是从性能的角度来看就好了。

You can still model relationships in MongoDB with separate collections BUT there are no joins in the database so you have to do that in code. Loading a User and then loading their Accounts might be just fine from a performance perspective.

您可以索引上的文档数组。不要以为一个指数作为摆明上的文档（如SQL）一个简单的场索引。您可以使用，比如说，一个标记集合上的文档和索引标签。 （请参见 http://www.mongodb.org/display/DOCS/Indexes#Indexes-Arrays）

You can index INTO arrays on documents. Don't think of an Index as just being an index on a simple field on a document (like SQL). You can use, say, a Tag collection on a document and index into the tags. (See http://www.mongodb.org/display/DOCS/Indexes#Indexes-Arrays)

在检索或写入数据你可以做一个部分读取任何文件的部分写。 （请参见 http://www.mongodb.org/display/DOCS/Retrieving+a+ +字段的一个子集+）

When you retrieve or write data you can do a partial read and a partial write of any document. (see http://www.mongodb.org/display/DOCS/Retrieving+a+Subset+of+Fields)

最后，当你无法看到如何得到你想要使用集合和索引的，你也许能够使用地图缩小来实现它。例如，要查找所有其使用频率排序的当前使用的标签，你会的地图的每个文件发射它使用的标记，然后你会的降低的那一套得到你想要的结果。那么你可能会存储映射的结果，减少永久也是唯一多达日起，当您需要

And, finally, when you can't see how to get what you want using collections and indexes, you might be able to achieve it using map reduce. For example, to find all the tags currently in use sorted by their frequency of use you would map each document emitting the tags used in it, and then you would reduce that set to get the result you want. You might then store the result of that map reduce permanently and only up date it when you need to.

的另外一个担忧：您可以通过标签注明计算总数。如果你想会计品质事务一致性，MongoDB的可能不适合你的正确选择。 - 最终一致性是游戏NoSQL数据存储的名称，他们一般不适合进行金融交易。例如，如果一个用户看到一个博客帖子有3条评论，而另一个认为4，因为他们打不同的复本的不同步呢，但对财务会计报告，那种一致性的事情确实也没关系 - 你报告可能不上！的

这篇关于为对象MongoDB的关系的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！