MongoDB 新手在这里。假设像这张图片一样的设计,根据我在谷歌上搜索的教程和信息,我打算Member
收藏一个。原因是,这将成为我正在构建的系统的用户最常见的入口点。s 的数据OtherEntity
将嵌入到Member
文档中。
此外,无论是否Group
会获得自己的集合,GroupLeader
都将始终是Group
.
那么,我该怎么处理Group
呢?以下三个选项似乎都不是接近此设计的好方法:
Group
作为子文档嵌入Member
作为
Group
一个单独的集合,将Member
s嵌入到Group
s 中。作为
Group
一个单独的集合,并且只将一个引用放入Member
我不想选择选项 1 的主要原因:因为在将Member
s 分配给时Groups
,我需要知道哪些Group
s 是“当前”,哪些是“过期”或“关闭”(因此不能再分配)。因此 aGroup
会有一个“IsActive”标志或类似的东西,为了保持一致性,需要在所有成员中更新它(如果我要将Group
s 嵌入到Member
s 中)
选项 2 似乎是一种反模式(就像Group
有一个Member
s 的有界数组一样)。此外,正如我上面所说,应用程序用户的主要入口点是Member
s。
选项 3 似乎是一种更关系到事物的方法,这似乎不是在 MongoDB 中处理事物的好方法?无论如何,在阅读有关 a 的信息时Member
,总是需要显示(至少一些)有关Group
该Member
所属的信息。这似乎表明嵌入将/应该是首选选项(即选项 1)。
这让我想到了我打算处理它的方式和我的问题:
拥有一个Group
充当“原型”的 s 集合 - 该集合包含有关 a 的所有信息Group
,包括Member
当前是否可以分配 s。此外,我会将 a 的所有必需数据点嵌入(不引用)Group
作为Member
子文档。Group
然后从集合的相应“原型”复制此类子文档的数据。
我说得有道理吗?这是一种可接受/好的方法,还是我落入了反模式?还有其他我应该考虑的事情吗?这种“模式”有合适的名称吗?对不起,如果这是一个愚蠢的问题,真的很难打破关系思维^^'
感谢所有的答案和见解,
干杯,CG