首页 > 解决方案 > 如何在 MongoDB 中管理一对多的关系更新

问题描述

TLDR;

  1. 当嵌套对象中引用的数据发生更改时,如何更新 MongoDB 中的嵌套对象?
  2. 简单地将 ID 存储在嵌套对象中并让客户端查找要显示的正确值有什么缺陷?

背景

我有一个应用程序,我相信它可以从使用文档数据库(例如 MongoDB)而不是当前的 SQL 后端中受益匪浅。生成的模型中的文档结构将涉及相当多的嵌套(2-3 层)。这样做的问题是嵌套对象的内容可能会在包含该嵌套对象的文档的上下文之外进行更新。在关系/规范化模型下,这很简单——每当我们更新嵌套对象(即数据库行)时,更新会自动通过 JOIN 拉入。但是,我知道尝试进行这种 JOIN/查找几乎违背了首先使用文档数据库的目的......

我的担心(也许是没有根据的)是我从切换到 Mongo 获得的任何好处(例如,消除向/从客户端序列化数据的复杂性,更快的读/写等)将通过必须找到的努力/复杂性来减轻并更新使用已更改对象的任何文档。我知道有办法 做到 一点,但它似乎非常麻烦且容易出错。

关系是不可避免的

尽我所能解决这一切,我相信关系和更新嵌套数据的需要是不可避免的。本质上,当在客户端输入将成为文档的数据时,用户需要从下拉框中选择项目。这些项目中的一些数据(例如显示名称)有时会更新。任何引用这些项目的文档都需要使用项目当前包含的任何数据进行更新。

可能的解决方案

目前,客户端接收所有查找表(填充选择框)作为应用程序状态的一部分。因此,我最初的直觉是简单地将参考项的 ID(永远不会改变)存储在文档中,并让客户端从自己的状态中查找正确的显示值。这避免了更新引用特定项目的所有文档的需要,并且还消除了后端的任何连接。但是,我担心我在这个解决方案中遗漏了一些可能导致我的应用程序出现问题的东西。显而易见的是,这会导致客户端和后端之间存在一定程度的耦合。

所以这让我回到上面的问题:

  1. 当数据引用可能更改的其他对象时,是否有一种不麻烦/可靠的方法来更新现有文档中的数据?
  2. 我提出的简单地将 ID 存储在文档中并迫使客户弄清楚要向用户显示什么的解决方案是否存在任何缺陷?

ps 也许这个问题更适合软件工程?如果是的话,很高兴把它移到那里......

标签: databasemongodbnested

解决方案


推荐阅读