【问题标题】:Without JOINs, what is the right way to handle data in document databases?如果没有 JOIN,那么在文档数据库中处理数据的正确方法是什么?
【发布时间】:2014-10-23 16:59:31
【问题描述】:

我了解 JOIN 在文档数据库中要么是不可能的,要么是不受欢迎的。我来自关系数据库背景,并试图了解如何处理此类情况。

假设我有一个员工集合,用于存储所有员工相关信息。以下是典型的员工文档:

{
   "id": 1234,
   "firstName": "John",
   "lastName": "Smith",
   "gender": "Male",
   "dateOfBirth": "3/21/1967",
   "emailAddresses":[
      { "email": "johnsmith@mydomain.com", "isPrimary": "true" },
      { "email": "jsmith@someotherdomain.com", "isPrimary": "false" }
   ]
}

假设我有一个单独的 Projects 集合,我在其中存储看起来像这样的项目数据:

{
   "id": 444,
   "projectName": "My Construction Project",
   "projectType": "Construction",
   "projectTeam":[
      { "_id": 2345, "position": "Engineer" },
      { "_id": 1234, "position": "Project Manager" }
   ]
}

如果我想返回我的所有项目以及项目团队的列表,我该如何处理以确保我返回有关团队中个人的所有相关信息,例如全名、电子邮件地址等?

是两个独立的查询吗?一个用于项目,另一个用于 ID 出现在项目集合中的人员?

如果是这样,我该如何插入有关人员的数据,例如全名、电子邮件地址?然后我是否在我的应用程序中执行一个 foreach 循环来更新数据?

如果我依靠我的应用程序来处理填充所有相关数据,这不是会抵消 MongoDB 等文档数据库的性能优势的性能损失吗?

感谢您的帮助。

【问题讨论】:

    标签: sql mongodb document mongodb-query azure-cosmosdb


    【解决方案1】:

    “...我如何确保返回有关团队中个人的所有相关信息,例如全名、电子邮件地址等?这是两个单独的查询吗?”

    它可以是 2 个单独的查询,也可以是非规范化到项目文档中。在我们的应用程序中,我们执行第二次查询,并在文档中尽可能地保持数据标准化。

    实际上,除了顶级文档之外的任何地方都不会看到“_id”键。此外,对于您将包含数百万个文档的集合,您可以通过保持键“简洁”来节省存储空间。考虑“name”而不是“projectName”、“type”而不是“projectType”、“pos”而不是“position”。这似乎微不足道,但它加起来。您还需要在“team.empId”上放置一个索引,以便查询“Joe Average 从事过多少项目”运行良好。

    {
      "_id": 444,
      "name": "My Construction Project",
      "type": "Construction",
      "team":[
        { "empId": 2345, "pos": "Engineer" },
        { "empId": 1234, "pos": "Project Manager" }
      ]
    }
    

    要习惯的另一件事是,您不必每次想要更新单个字段或例如向团队添加新成员时都编写整个文档。您可以进行有针对性的更新,以唯一标识文档,但只更新单个字段或数组元素。

    db.projects.update(
      { _id : 444 },
      { $addToSet : "team" : { "empId": 666, "position": "Minion" } }
    );
    

    完成一件事的 2 个查询一开始很痛苦,但你会克服它的。

    【讨论】:

      【解决方案2】:

      Mongo DB 是一个文档存储数据库。 它支持高可用性和可扩展性。

      要返回所有项目的列表以及项目团队(详细信息), 根据我的理解,您将必须运行 2 个查询。 由于 mongoDb 没有 FK 约束,我们需要在程序级别对其进行维护。 代替 FK 约束, 1)如果数据较少,那么我们可以将数据嵌入为子文档。 2)而不是规范的设计db的方式,在MongoDb中我们需要根据访问模式进行设计。即我们需要更有可能查询数据的方式。 (不过更新的时间比较多(慢),但是在用户端性能主要取决于读取活动,会比RDBMS好)

      以下链接免费提供有关 mongo Db 的证书课程。 Mongo DB University 他们还有一个论坛,很不错。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2012-11-01
        • 2021-07-06
        • 2021-02-10
        • 2015-04-13
        • 1970-01-01
        • 1970-01-01
        • 2020-05-15
        • 1970-01-01
        相关资源
        最近更新 更多