Question

好的，我会开始说我不是新手，但我正在寻找最好的解决方案。

为简单起见，我有四方关系：

Busines
{
 bid: unique,
 name: string
}

Client
{
 cid: unique,
 name: string
}

Product
{
 pid: unique,
 name: string
}

Order
{
 oid: unique,
 bid: FK,
 cid: FK,
 pid: FK
}

在Mongo中建立这个的最佳方法是什么？

请注意，同一客户端也可以在许多企业和同一产品中使用。

所以有时我需要通过客户的所有订单进行选择，并按业务和其他时间按产品分组数据。

Answer 1

考虑您的评论：

我同意，但问题在于速度和MongoDB的Sharding / Replication比例如MySQL好......而且我将有很多小的Order元素（以百万计），这里RDBS将有这是不利的...... :(

我相信你看错了。 MongoDB只会比RDBMS更快，如果它适合您的场景，以使其更快。

在大多数数据库中，数百万行甚至不值得分片，甚至商品服务器也可以处理至少几兆兆字节的信息。分片来自增加写入容量的需求，就像在RDBMS技术中一样，而不是必须从数据的大小。

然而，为了回答架构问题，我会暂时保留它，除非我删除订单并替换客户端内部：

{
    _id: ObjectId(),
    name: 'sammaye',
    orders: [
        {oid:{},bid:{},cid:{},pid:{}},
        { //etc }
    ]
}

这是一个很小的meger对象，不应该造成太多的问题，并且它不会每天增加100个，所以不应该造成严重和立即的碎片。

如果您发现它确实会导致您的流量和订单率出现碎片，那么您可以随时使用2种尺寸分配（http://docs.mongodb.org/manual/reference/command/collMod/）的功能来帮助解决问题，但是我应该警告说这实际上在短期内效果不佳所以不要在不需要的情况下应用此选项。

也就是说，根据您提供给我们的信息。我将如何设计该架构。

Answer 2

要提供替代方法，您可以将Clients保留为单独的集合，并在Product中嵌入Order个信息（至少部分）。

通常很重要的是要知道客户在下订单时订购了什么（以及他们支付的价格，货币等）。您仍然可以参考该产品，但这意味着您可以查看历史订单并实际查看他们当时购买的产品。产品细节会随着时间的推移而合法地发生变化。

这仍然意味着快速阅读;我假设业务集合比客户端小得多，所以也许你可以在应用程序级别处理（即缓存业务，这样你就不会在数据库中查找每个内容）

我很欣赏我所谈论的很多信息目前不在产品文档中，但可能需要考虑。

当然有文档大小限制，如果您对产品信息（或其中一些）进行非规范化，并且单个客户可以为许多企业下订单，则需要检查您是否有权将此信息保存在客户中集合 - 但这取决于订单数量和订单数量等。

无论如何，已经有一些关于表演等技术性的好答案，只是觉得我会提出不同意见。

这个数据的最佳MongoDb架构是什么？

2 个答案: