MongoDB架构图答案

【问题标题】：MongoDB schema diagramMongoDB架构图
【发布时间】：2016-03-25 22:11:56
【问题描述】：

在类图（UML 格式）中绘制 mongodb 架构图是否可行，因为 ER 图更多地与 SQL 相关。
在高层schema中表示id时，以下3个中哪个类型正确：(int or objectId or _id)
```
id: int
```
或
```
id: bson.ObjectId
```
或
```
id: _id
```

在架构图中表示子文档对象时，以下2个中哪个类型正确（字符串或对象）

comments : String [
                    {
                      userName : String
                      date : String
                      actualComment : String
                    }
                  ]

或

comments : Object [
                    {
                      userName : String
                      date : String
                      actualComment : String
                    }
                  ]

更新

如果我有以下子文档（这里是 JSON 表示），Mongo 如何存储回复 - 它是什么类型？

    comments : String [
                        {
                          userName : String
                          date : String
                          actualComment : String
                          replies : comment [ ] // how does mongo store nested replies
                        }
                      ]

【问题讨论】：

_id 隐含地是每个文档的一部分。因此，您可能会考虑省略它，除非您将其替换为特定于应用程序的值。
@Philipp 问题是什么类型。 _id 是隐式字段，但类型是ObjectId。
回复和cmets怎么样。在 JSON 中，回复采用评论类型，但它在 mongo 中是如何表示的？

标签： mongodb

【解决方案1】：

可行，但不适用于所有情况。 FK relationships can be represented the same way. For arrays, embedded, etc. you'd have to establish a representation/interpretation.
ObjectID 是类型；那是BSON type。 _id 是字段名称。不知道int 是怎么落后的，BSON 类型是 32 位整数 和 64 位整数。
没有。它只是一个（子）文档。

更新

从技术上讲，它是一个数组。没有具体类型。在这种情况下，您可能会想到一组 ids 评论实体，但可能是您想要的任何东西（包括子文档）。

【讨论】：

谢谢，如果我有以下子文档（这里是 JSON 表示），mongo 如何存储回复 - 它是什么类型的？ cmets : String [ { userName : String date : String actualComment : String replies : comment [ ] // mongo 如何存储下一个回复 } ]
我报告为答案，因为我无法在此评论中正确格式化
@tyonne 如果您有后续问题，请提出新问题。
我将您的答案内容复制到了您的问题中。这就是应该这样做的方式。请删除您的答案。

【解决方案2】：

UML 类图用于面向对象编程中的类，ER 图用于关系数据库中的关系。 MongoDB 既不是对象数据库也不是关系数据库，因此这两种工具都不是真正适合 MongoDB 的工具。但是只考虑这两个工具，我宁愿使用 UML 类图，因为 ER 强调了在 MongoDB 中最好避免的东西：文档之间的关系。

默认情况下，_id 字段填充了 BSON ObjectId 类型的生成值，因此如果您使用默认值，您的第二个示例 bson.ObjectId 在技术上是正确的。但是，您没有必须使用默认值。您还可以将您的 _id 字段显式设置为您想要的任何类型的自己的值。因此，如果您出于某种原因想为您的 ObjectId 使用整数（请记住，您需要注意保持它们的唯一性），您当然可以这样做，并且应该在您的文档中说明。当您不为 _id 使用自定义值并且也不使用它们时，您可能会考虑从图表中省略它们，因为它们是隐含的。

在我看来，在 UML 类图中，嵌入文档最好使用组合（黑色菱形箭头）表示，而引用文档则使用聚合（白色菱形箭头）表示。子文档绝对不是String。 Object 更好，但更好的是使用正确的类型。

关于您的后续问题：无限嵌套的数据结构（具有 cmets 数组和 cmets 数组的 cmets...）可以通过指向它来自的框的组合箭头在 UML 中可视化。但请记住，此类数据结构不适合 MongoDB，通常最好避免使用。我宁愿建议您将每条评论放入一个自己的文档中，该文档引用它所属的主题和父评论（聚合）。但即使这样也不是一个特别优雅的解决方案。 MongoDB 不是为存储图表而构建的。

【讨论】：