问题标签 [document-oriented-db]

我需要如何或以何种方式将大于机器内存的数据量存储到数据库中（例如数据为 20 GB，RAM 为 16 GB）。考虑到我使用的是一台机器，并且所有数据都是面向文档的（NoSQL）

在理解何时以及为什么在 mongo 数据库中使用嵌入式文档时遇到了一些麻烦。

想象一下，我们有三个集合：用户、房间和预订。

对于这样的情况，我有几个问题：

1）您将如何更新嵌入的文档？应用程序开发人员是否有责任将 kevin 的所有实例作为嵌入式文档查找并更新它？

2）如果解决方案是使用文档引用，那是否和关系数据库连接一样重？这只是示例不适合 Mongo 的一个例子吗？

像往常一样让我知道我是不是一个彻头彻尾的白痴。

我有一个名为“feed”的集合

每个文档中都有名为“status”和“scheduleDate”的键。

我想在 scheduleDate 键上设置一个基于 ttl 的索引，但只有那些文档应该被删除

有没有办法做到这一点？

我需要使用具有 id 的对象数组来更新 MongoDB 字段，需要在 JSON 对象中使用相同的 id 进行更新

如果我在 MongoDB 中有类似的东西

我有这样的 JSON 数据要插入 Mongo

更新后，我需要 Mongo 集合中这样的最终数据

我不擅长文档数据库，想提高自己。任务是：将企业层次结构存储到 Mongo DB 中。

有雇主和部门。每个雇主都属于一个特定的部门（顺便说一句，如果有人属于多个部门怎么办？）。当然，有员工等级制度：主管是根。所以除了主管之外的每个人都有一个直属上司（如果有人有多个不是来自同一分支的上司怎么办？）

结构可以更改（可以说每天不超过一次）并具有时间戳。

那么如何将其存储到 Mongo DB 中呢？多收藏？还是一个集合和许多文档？

所有可行的想法都值得赞赏。

我最近开始学习 NO SQL 数据库，并且遇到了面向键值的数据库和面向文档的数据库。由于它们具有相似的结构，它们的保存和检索方式不是完全相同吗？如果是这样的话，那么为什么我们将它们定义为单独的类型呢？否则，它们是如何保存在文件系统中的？

MongoDB 新手在这里。假设像这张图片一样的设计，根据我在谷歌上搜索的教程和信息，我打算Member收藏一个。原因是，这将成为我正在构建的系统的用户最常见的入口点。s 的数据OtherEntity将嵌入到Member文档中。

此外，无论是否Group会获得自己的集合，GroupLeader都将始终是Group.

那么，我该怎么处理Group呢？以下三个选项似乎都不是接近此设计的好方法：

1. Group作为子文档嵌入Member

2. 作为Group一个单独的集合，将Members嵌入到Groups 中。

3. 作为Group一个单独的集合，并且只将一个引用放入Member

我不想选择选项 1 的主要原因：因为在将Members 分配给时Groups，我需要知道哪些Groups 是“当前”，哪些是“过期”或“关闭”（因此不能再分配）。因此 aGroup会有一个“IsActive”标志或类似的东西，为了保持一致性，需要在所有成员中更新它（如果我要将Groups 嵌入到Members 中）

选项 2 似乎是一种反模式（就像Group有一个Members 的有界数组一样）。此外，正如我上面所说，应用程序用户的主要入口点是Members。

选项 3 似乎是一种更关系到事物的方法，这似乎不是在 MongoDB 中处理事物的好方法？无论如何，在阅读有关 a 的信息时Member，总是需要显示（至少一些）有关Group该Member所属的信息。这似乎表明嵌入将/应该是首选选项（即选项 1）。

这让我想到了我打算处理它的方式和我的问题：

拥有一个Group充当“原型”的 s 集合 - 该集合包含有关 a 的所有信息Group，包括Member当前是否可以分配 s。此外，我会将 a 的所有必需数据点嵌入（不引用）Group作为Member子文档。Group然后从集合的相应“原型”复制此类子文档的数据。

​我说得有道理吗？这是一种可接受/好的方法，还是我落入了反模式？还有其他我应该考虑的事情吗？这种“模式”有合适的名称吗？对不起，如果这是一个愚蠢的问题，真的很难打破关系思维^^'

感谢所有的答案和见解，

干杯，CG