mongodb 我是否应该在no-sql中嵌套我经常查询的元素?

zed5wv10  于 2023-05-17  发布在  Go
关注(0)|答案(1)|浏览(113)

我在MongoDB中有一个非关系数据库,其中我存储了具有以下结构的项目:

{
      "_id": "64586748c079e955385c18af",
      "operator": "KILIN",
      "department": "EXAMPLE-DEPARMENT",
      "city": "MIAMI",
      "locality": "Usaquén",
      "neighborhood": "LISBOA",
      "start_date": "2023-04-29",
      "final_date": "2023-04-29",
      "reason": "programed",
      "description": "AV 88 # 8123",
      "status": "not_validated",
      "customers_affected": [
        {"ENEL-BOG-00013":{"name": "tecniglas", "Phone": 3456752}},
        {"ENEL-BOG-00111":{"name": "pepsi", "Phone": 2354321}},
      ]
    }

该数据库处理许多服务中断警报。我的问题集中在“受影响的客户”元素上。该国有许多客户,每个警报都会根据他们的位置影响他们。我将不断地要查询客户的每一个警报发送通知(无论是通过短信或电子邮件)。我的疑问是,我是否应该让它保持结构化,或者我是否应该将所有客户端保存在另一个集合中,并以某种方式将它们与警报联系起来。

f0brbegy

f0brbegy1#

列出你的优点和缺点。(注:我并不是说这是详尽无遗的)

选项1:将客户数据保存在同一文档中

优点:

  • 在一次操作中更容易查询和更新客户数据。
  • 减少数据重复,因为每个客户的客户数据仅存储一次。

缺点:

  • 如果有许多客户,文档可能会变得非常大,这可能会影响查询性能。
  • 客户数据没有规范化,这可能会使其更难以管理和维护。
    选项二:将客户数据存储在单独的集合中并将其与警报链接

优点:

  • 规范化数据,使其更易于管理和维护。
  • 允许更好地分离警报数据和客户数据之间的关注点。
  • 可以通过减小文档大小来提高查询性能。

缺点:

  • 需要额外的查询来获取相关的客户数据,这可能会影响性能。
  • 需要维护警报和客户之间的关系,这可能会增加应用程序的复杂性。

由您来决定哪个选项最适合您的用例。如果您的客户数量相对较少,并且不希望频繁更新,则将客户数据保存在同一文档中可能是一种更简单、更有效的方法。但是,如果您预计会有大量的客户和频繁的更新,则将客户数据存储在单独的集合中并将其与警报链接可能是性能和可维护性的更好选择。并且:由于您必须经常查询客户以获取每个警报以发送通知,因此最好将客户存储在单独的集合中,并使用唯一标识符将其链接到警报。
注意:这是“一般性”的React,没有关于体积或预测生长的太多信息,也没有执行任何测试的能力。

相关问题