Architecture 存储单个“的惯用方法”；头等舱；MongoDB中的列表？

我有一个特殊的列表（一种队列，在数据结构中，而不是在工作队列中），我想存储在MongoDB中。在我的应用程序中，我需要经常访问和操作这个列表，但我没有几种相同类型的列表

将其存储在单个文档中是最容易的，但我遇到的问题是找出从我的应用程序代码中引用该特定文档的最佳方法。我不希望必须查询多个文档才能找到正确的文档，因为只有一个文档将包含此列表

我也不希望将列表拆分为一个集合中的多个文档，因为它只是一个简短的列表（它限制为400个元素，每个元素只是一段短文本，因此没有超出4MB文档限制的风险）

我想了好几种方法，但似乎都不理想。请让我知道一个方法是否正确，或者我是否遗漏了什么

为文档设置自定义的

\u id

，并在我的应用程序中对其进行硬编码

为文档创建一个集合，该集合将只包含一个文档，这样我就可以通过获取该集合中的第一个文档来检索它。（这似乎有点骇人）

使用类似于

document\u name:“我的特别列表”

的字段，通过查询

document\u name

检索文档。我不想这样做，因为我不需要像这样的其他文档，所以只有一个文档会有

document\u name

字段

使用一个文档集合，每个文档包含一个索引字段和一个元素内容字段，并使用map reduce从中获取列表，或者沿着这些行的其他内容。我不希望这样做，因为简单地检索BSON列表、操作它并将其存储回文档中要简单得多

使用不同的技术来实现这一点，因为MongoDB不适合它

各国：

欢迎用户使用自己的约定创建ID；

\u id

值可以是任何类型，只要它是唯一的

所以我会选择第一种方法

更新 正如您自己所说，选项2有点像黑客。
选项3为某些内容引入了一个附加字段，您也可以将

\u id

字段用于该内容。

---

选项4是一个简单问题的复杂解决方案。

我知道这一点，但我不确定它是否主要是为了允许替代ID方案（如将SQL数据映射到mongodb并使ID对齐），或者是否将其用于“命名”特殊文档。我觉得这样使用“id”是一个特例，而不是像文档中所说的那样建立一个新的“约定”。@Wahnfrieden:我更新了我的答案，以澄清为什么选项1是所有四种解决方案中最好的解决方案。你是对的，这不是一个真正的惯例，因为这是一个一次性的案例。但是您可以定义一个

namedDocuments

集合，其中所有文档都有一个用户定义的

\u id

约定；）谢谢你的更新。我想我只是希望我错过了另一个选择。