0

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

为简单起见，我有 4 向关系：

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 中构建它的最佳方法是什么？

请注意，同一个客户也可以在许多业务和同一个产品中。

所以有时我需要根据客户的所有订单进行选择，并将数据按业务分组，有时按产品分组。

4

2 回答 2

1

考虑到您的评论：

我同意，但问题在于速度，例如 MongoDB 的分片/复制比 MySQL 更好......而且我将有很多小订单元素（以百万计），这里 RDBS 将有它的劣势。 .. :(

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

在大多数数据库中，数百万行甚至不值得分片，即使是商品服务器也可以处理至少几 TB 的信息。分片来自于增加写入容量的需要，就像它在 RDBMS 技术中所做的那样，而不一定来自于数据的大小。

但是，要回答架构问题，我会保持原样，除非我会删除订单并在客户端内部替换它：

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

它是一个小而巨大的对象，不会造成太多问题，也不会每天增加 100 个，因此不会造成严重和直接的碎片。

如果您发现它确实会导致您的流量和订单率碎片化，您总是可以使用 2 大小分配的力量（http://docs.mongodb.org/manual/reference/command/collMod/）来提供帮助，但是我应该警告这实际上在短期内性能较差，因此不要在不需要它的情况下应用此选项。

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

于 2013-02-26T11:10:58.693 回答
0

要提供另一种方法，您可以将其保留Clients为单独的集合，并将（至少部分）Product信息嵌入到Order.

在下订单的时间点了解客户订购的内容（以及他们支付的价格、货币等）通常很重要。您仍会保留对产品的引用，但这意味着您可以查看历史订单并实际查看客户当时购买的商品。产品细节随着时间的推移合法地改变。

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

我很欣赏我正在谈论的大部分信息目前不在产品文档中，但可能需要考虑一些事情。

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

无论如何，已经有一些关于性能等技术的很好的答案，只是想我会提供不同的意见。

于 2013-02-27T08:54:44.337 回答