可以嵌入或独立的文档的 MongoDB 模式设计答案

【问题标题】：MongoDB schema design for document that can be embedded or stand alone可以嵌入或独立的文档的 MongoDB 模式设计
【发布时间】：2012-04-01 21:52:02
【问题描述】：

我对 MongoDB 还比较陌生，并且还在习惯模式设计。

在我目前正在进行的项目中，用户可以标记他们上传的文件。共有三种类型的标签：描述性、品牌和 store_department。它们以三个字段的形式呈现给用户，但实际上它们被合并在一起并保存为标签，即：

"tags" : [
  {
    "type" : "descriptive",
    "tag" : "this is my tag"
  },
  {
    "type" : "brand",
    "tag" : "this is another tag"
  }
]

这是为了使搜索变得非常容易。通过使用类型，我可以向用户展示三个不同的字段，以鼓励他们提供信息，然后允许进行更高级的查询，例如按品牌或商店部门进行搜索。默认搜索只会搜索匹配的标签。

问题是我在所有字段中都提供了自动完成功能。当用户在“品牌”字段中键入时，所有创建的类型为“品牌”的标签都会显示与他们的输入相匹配。这很容易通过拥有一个独立的标签集合来实现。保存文件文档时会创建和更新新的标签文档。针对独立标签集合而不是嵌入式标签的自动完成查询以提高性能。

这种设计感觉有些不对劲。在某些方面这是重复的努力，但就用户体验而言似乎效果很好。我使用 Mongoid，为了适应这种设计，我不得不为我的标签集合创建两个模型。一个定义两个属性，另一个从第一个继承，但添加了 embedded_in 宏。

我可以看到这种模式在其他情况下也很有用：产品和购物车、产品和采购订单等。还有更好的方法吗？

【问题讨论】：

【解决方案1】：

这种设计感觉有些不对劲。在某些方面这是重复工作，但就用户体验而言似乎效果很好。

在 NoSQL 数据库中，有时您必须进行非规范化。这将导致一定数量的数据重复。但由于它可以极大地提高性能（并且非常适合用户体验），因此应该值得。

因此，用于自动完成的具有不同标签名称的集合可能是有意义的。它将比嵌入文档中的非独特标签小得多。这种方法没有错。

这个“主”集合是为标签添加额外元数据的好地方，例如 Stackoverflow 的描述和 wiki 此处的标签。

此外，如果只有几种类型，最好为每种类型的标签设置一个单独的字段。这样，您可以单独索引它们。

"tags" : { "descriptive: [ "this is my tag" ],
           "brand": ["this is another tag" ] }

【讨论】：