mongodb 子文档是否等同于 Firestore 子集合? [英] Is mongodb sub documents equivalent to Firestore subcollections?

问题描述

对于那些使用 Firebase (Firestore) 的人，您可以拥有一个包含文档的集合，其中每个文档都有一个 id，然后一个集合可以包含一个子集合(相当于一个嵌入文档作为文档数组作为属性).

For those of you who worked with Firebase (Firestore), then you can have a collection with documents in which each document has an id, then a collection can hold a sub collection (equivalent of an embedded document as an array of documents as a property).

然后，这个子集合可以容纳许多文档，每个文档都有一个 id.

Then, this sub collection can hold many documents while each has an id.

在 Firestore 中，子集合是延迟加载的.

In Firestore the sub collection is lazy loaded.

它将获取该集合上的文档，但如果有一个或多个子集合，除非专门转到该路由，否则它将不会检索它.例如:collection/document/subcollectionname/anotherdocument

It will fetch the documents on that collection, but if there is one or more sub collections, it won't retrieve it unless specifically going to that route. e.g: collection/document/subcollectionname/anotherdocument

所以 2 个问题:

1. 嵌入式文档是否延迟加载?除非我明确访问它，否则我不想获取包含所有嵌入文档(可能有一百万个)的文档.
2. 如何确保 MongoDB 中的每个嵌入文档都有一个_id"?以 ObjectID(blablabla") 的形式?

编辑:我目前有一个 Firestore 实现，它背后有一个子集合实践.

EDIT: I currently have a firestore implementation which has a subcollection/s practice behind it.

示例:组织 =>documentId =>项目 =>projectId =>活动 =>:activityType =>activityId

Example: organization => documentId => projects => projectId => activities => :activityType => activityId

1. 组织 包含文档的集合(每个文档 = 组织).
2. 每个组织文档都包含一个架构(id、名称、语言等.)和一些子集合，其中一个是 projects 子集合
3. projects 子集合包含 projects 的文档.
4. 一个项目文档包含项目架构(id、名称、位置等.)和一个名为activities的子集合.
5. activities 子集合拥有自己的架构(id、type、category 等...)和另外 6 个子集合，每个子集合代表一个活动类型.
6. 每个活动子集合都有自己的架构.没有更多的子集合.

1. organization collection that holds documents (each document = organization).
2. Each organization document holds a schema (id, name, language, etc..) and a few subcollections in which one of them is projects subcollection
3. projects sub collection holds documents of projects.
4. a project document holds the project schema (id, name, location, etc..) and one subcollection named activities.
5. activities sub collection holds its own schema (id, type, category, etc...) and 6 more sub collections, each represents an activity type.
6. each activity sub collection holds its own schema. No more sub collections.

现在，这样做的好处是，如果我选择获取所有组织，那么我将仅获取组织 collection 的 文档，而不是嵌入的子集合(projects、etc..)在 MongoDB 中，我会得到每个文档的 EVERYTHING.

Now, the good thing about it is that if I choose to get all organizations, then I will get only the documents of the organization collection and NOT the embedded subcollections (projects, etc..) while in MongoDB, I would get EVERYTHING per document.

如何在MongoDB中实现具有自己的嵌套文档结构和延迟加载效果的相同嵌套文档?

How do I achieve the same nested documents with their own nested documents structure with the lazy load effect in MongoDB?

推荐答案

一个项目可以有多少个活动?如果没有限制，那么您最好为活动创建一个根级别的集合.在 MongoDB 中，最大 BSON 文档大小为 16 MB.您可能无法将所有项目及其活动存储在单个文档(组织文档)中.

How many activities can a single project have? If there's no limit then you're better off creating a root level collection for activities. In MongoDB, the maximum BSON document size is 16 MB. That being you may not be able to store all projects and their activities in a single document (organization document).

我将创建 3 个集合，即 - 组织、项目和活动.

I would create 3 collections namely - organizations, projects and activities.

1. 每个组织都应该在 organizations 集合中拥有一个类似于 Firestore 中的文档.
2. 每个项目都应该在 projects 集合中有一个包含字段organizationID"的文档.因此您可以使用他们的 ID 查询特定组织的项目.这相当于您的项目子集合中的文档.每个项目还必须有自己的唯一 ID.
3. 每个活动都应该在 activities 集合中有一个文档，其中包含一个字段projectID".因此可以检索特定项目的活动.

1. Each organization should have a document in organizations collection similar to that you have in Firestore.
2. Each project should have a document in projects collection containing a field "organizationID" so you can query projects of a specific organization using their ID. This is equivalent of a document in your projects sub-collection. Every project must also have it's own unique ID.
3. Each activity should have a document in activities collection containing a field "projectID" so activities of a specific project can be retrieved.

我已经添加了那些额外的 organizationID、projectID 字段，即使您有 _id 以防万一您想要 Firestore 文档那里的 ID 可以更轻松地进行并行查询.

I've added those additional organizationID, projectID fields even though you have _id just in case you'd like to have Firestore Document IDs there for easier side-by-side queries.

通过这种方式，您不必担心 16 MB 文档大小限制，只要您有正确的 ID，查询项目和活动就会更容易.

You don't have to worry about 16 MB document size limit this way and it'll be easier to query both projects and activities as long as you have the correct IDs.

查询某个项目的活动:

await db.collection("activities").find({projectID: "myProjectID"}).toArray()

此后，如何编写带有投影、聚合等的查询由您决定.

Thereafter it's upto you how you want to write queries with projections, aggregation, etc.

这篇关于mongodb 子文档是否等同于 Firestore 子集合?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！