Question

试图通过关系数据库背景来掌握MongoDB。

我相信MongoDB的一个主要概念是尽可能多地保存数据。

想象一下，我创建了一个包含产品和类别的应用程序，并以这种方式存储产品：

产品系列

{
    "_id": "30671", //main item ID
    "department": "Shoes",
    "category": "Shoes/Women/Pumps",
    "brand": "Calvin Klein",
    "thumbnail": "http://cdn.../pump.jpg",
    "title": "Evening Platform Pumps",
    "description": "Perfect for a casual night out or a formal event.",
    "style": "Designer",
    …
}

类别集合

{
    "_id": "12356",
    "name": "Shoes"
    …
}

如果我更新了类别名称，我是否还需要运行一个巨大的更新命令来更新所有产品？或者在这种情况下，最好将产品类别ID存储在产品而不是名称中（就像我们在关系数据库中那样）？

由于

Answer 1

一般来说，没有＆＃34;一刀切的＆＃34; MongoDB中的方法就像在关系数据库世界中一样。在关系模式设计中，将Category放在单独的表中是明智的。事实上，在规范化过程中几乎是要求这样做。

在MongoDB中，架构设计几乎完全取决于您的需求和用例，而不是任何经验法则或任何制定的要求。当然，每种选择都有优缺点。例如：

如果您在用例中发现Category变化不大（或根本没有），那么您可以放心地将其放在Products集合中。但是，如果您需要重命名某个类别，那么您需要更新属于该类别的所有产品。
如果您发现您的用例需要灵活地更改类别名称，那么您可能希望将其放入单独的集合中并像关系设计中那样引用它。但是，返回产品可能效率不高，因为现在您需要两个查询而不是一个（或查找）。

我注意到您在示例中使用了"category": "Shoes/Women/Pumps"。在MongoDB中，如果您的用例允许，可以将其放入数组中，例如： "category": ["Shoes", "Women", "Pumps"]。这个可能使字段更容易索引（同样，取决于您的用例）。

简而言之，MongoDB架构设计中没有对错，但有一点需要注意：通常错误的做法是尝试在MongoDB中模拟关系设计，因为它违背了粒度。

您也可以找到这些链接：

MongoDB更新范例

1 个答案: