MongoDB - 集合的正确使用？
在 Mongo 中，我的理解是你可以拥有数据库和集合。我正在开发一个社交类型的应用程序，该应用程序将有博客和评论（除其他外），并且之前一直使用 MySQL 和相当重的分区来尝试限制可能的并发问题。
使用 MySQL，我将所有用户数据填充到 _user 数据库中，其中包含多个表以进一步分区数据（博客、页面等）。
我对 Mongo 的第一反应是创建一个“用户”数据库，每个用户有一个集合。通过这种方式，用户“zach”博客条目将进入带有相关评论的“zach”集合，并且此类成为同一集合中的子对象。基本上就像在 MySQL 中为每个用户动态创建一张表一样，但显然没有可能施加的复杂性和限制。
当然，因为我之前没有真正使用过 Mongo，所以我很难衡量这个想法的（咳咳..）质量以及它可能导致的潜在问题。
我希望用户数据被像*nix环境中的用户目录一样对待，其中用户创建/非共享（大部分）被放入一个地方（目前使用MySQL，这将是如上所述的appname_users）。
大多数用户数据将特定于用户页面。在所有站点用户（可搜索的用户配置文件）中查询的一些用户数据当前保存在单独的数据库/表中，我希望这样的内容可以放入 appname_system 数据库中，并分解为集合和/或特定于应用程序的数据数据库（应用程序名称_配置文件）。
无论如何，由于目前有关这方面的可用文档有点薄弱，而且我的经验极其有限，我想我可能会从对系统有更好了解的人那里找到一些指导。
从好的方面来说，我确实已经尝试将 MySQL 视为无模式文档存储，而使用 Mongo 来实现这一点似乎更加直观/理智/合理，所以我真的很期待开始。
谢谢， 扎克
In Mongo my understanding is that you can have databases and collections. I'm working on a social-type app that will have blogs and comments (among other things) and had previously be using MySQL and pretty heavy partitioning in an attempt to limit possible concurrency issues.
With MySQL I've stuffed all my user data into a _user database with several tables to further partition the data (blogs, pages, etc).
My immediate reaction with Mongo would be to create a 'users' database with one collection per user. In this way user 'zach' blog entries would go into the 'zach' collection with associated comments and such becoming sub-objects in the same collection. Basically like dynamically creating one table per user in MySQL, but apparently without the complexity and limitations that might impose.
Of course since I haven't really used Mongo before I'm having trouble gauging the (ahem..) quality of this idea and the potential problems it might cause down the road.
I'd like user data to be treated a lot like a users directory in a *nix environment where user created/non-shared (mostly) gets put into one place (currently with MySQL that would be the appname_users as mentioned above).
Most of the users data will be specific to the users page(s). Some of the user data which is queried across all site users (searchable user profiles) is currently kept in a separate database/table and I expect things like this could be put into a appname_system database and be broken up into collections and/or application specific databases (appname_profiles).
Anyway, since the available documentation on this is currently a little thin and my experience is extremely limited I thought I might find a little guidance from someone with a better working understanding of the system.
On the plus side I'd really already been attempting to treat MySQL as a schema-less document-store and doing this with Mongo seems much more intuitive/sane/rational so I'm really looking forward to getting started.
Thanks,
Zach
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我有同样类型的应用程序。
需要考虑的一些事情：您可以在集合之间进行交叉查询，但不能在数据库之间进行交叉查询。
因此，最好拥有一个包含所有数据的数据库，然后为每个对象建立一个集合。
然后每个文档可以包含任意种类和数量的字段。
我试图避免嵌入数组，因为我在正确查询我的对象时遇到了麻烦（它工作正常，但我的系统的体系结构是为此用途而设计的）
并且数据库可以在多个服务器之间自动共享，因此空间不是问题（如果您有超过 1 台服务器）
I have the same kind of application.
Some things to consider: you can cross query between collection bu not between databases.
So It's probably better to have a database with all you data and then a collection for each Object.
Then each document can contain any kind and number of fields.
I tried to avoid embedding arrays b/c I had trouble query properly my object (it was working fine, but the architecture of my system was designed for this use)
And a database can be shared between several sever automatically so space is not an issue (if you have more than 1 server)