Mongo DB Design,嵌入与关系

我正在建立一个简单的会计系统,用户有很多账单.现在,我正在尝试决定账单应该是自己的集合,还是嵌套在用户中.我倾向于前者,但我从来没有做过任何noSQL的东西所以我只是通过反复试验和我认为对我有意义.

据我所知,Mongo有4mb的文件大小限制,这让我觉得我应该有一个单独的账单收集,因为这些将每天累积,最终可能占用大量空间.

我只是在寻找有关此事的意见.基本上我会查询不同日期之间的用户账单(你可以想象会计系统会这样做).

并不是真的很重要,但我在Rails3项目中使用Mongoid.我想我会做类似的事情:

class User
  references_many :bills
end

class Bill
  referenced_in :user
end

任何评论或设计建议都非常感谢.

1)关于4MB文档限制,这就是"MongoDB:The Definitive Guide"所说的:

Documents larger than 4MB (when converted to BSON) cannot be saved to the database. This is a somewhat arbitrary limit (and may be raised in the future); it is mostly to prevent bad schema design and ensure consistent performance. To see the BSON size (in bytes) of the document doc, run Object.bsonsize(doc) from the shell.

To give you an idea of how much 4MB is, the entire text of War and Peace is just 3.14MB.

In the end it depends on how big you expect the bills for a user to grow. I hope the excerpt above gives you an idea of the limits imposed by the document size.

2) De-normalized schema (bills go with the user document) is the way to go if you know that you are never going to run global queries on bills (example of such a query is if you want to retrieve the ten most recent bills entered into the system). You will have to use map-reduce to retrieve results for such queries if you use a denormalized schema.

Normalized schema (user and bills in separate documents) is a better choice if you want flexibility in how the bills are queried. However, since MongoDB doesn't support joins, you will have to run multiple queries every time you want to retrieve the bills corresponding to a user.

Given the use-case you mentioned, I'd go with de-normalized schema.

3) All updates in MongoDB are atomic and serialized. That should answer Steve's concern.

您可能会发现这些幻灯片很有用 http://www.slideshare.net/kbanker/mongodb-meetup

您还可以查看MongoDB的Production Deployments页面.您可能会发现SF.net幻灯片很有帮助.