Question

我有一个场景，我正在为我的应用辩论。

假设我有一个带有MongoDB结构的Quiz应用程序，如下所示：

{
  _id: xxxxxx,
  userId: xxxx,
  quizData: [
   {
    name: xxxx,
    quizId: xxxx, 
    questions: [...]
   },
   {
    name: xxxx,
    quizId: xxxx, 
    questions: [...]
   }
[...]
}

我在应用程序的长期更好之间徘徊：让每个用户只有一个文档，并且对于他/她创建的每个测验，它将被添加到“quizData”对象数组中......或者。 ..let每个用户的测验在MongoDB中都有自己的文档，我为每个测验创建了上述结构（显然，“quizData”只包含一个对象而不是多个数组）。

理论上，用户可以根据需要创建尽可能多的测验，但实际上，情况可能并非如此。我担心，如果我让每个用户都拥有MongoDB中每个测验的自己的文档，它将快速填充集合并随着时间的推移（许多用户都这样做），这将减慢查询过程。

有人对最佳方法有任何想法吗？

Answer 1

您的问题可以改写为one-to-many relationship with embedded documents VS one-to-many relationship with document references

没有更好或更差，这完全取决于您的使用案例。从长远来看，我认为最好与文档参考建立一对多关系，因为我可以想到这些原因：

文档大小限制为16mb，如果用户创建大量测验，该用户的文档将快速超过16mb的限制。
在所有用户的测验数量增长到数十亿之后的某个时刻，您可能希望对这些测验数据进行一些操作（例如：分析，优化等），但不要弄乱用户数据

Answer 2

如果您确定某个用户不会创建这么多测验，那么这可能只有少数几个，您可以将测验数据嵌入用户数据本身。这完全取决于您的数据访问模式。

示例如果您的数据访问模式是这样的，您通常会在每次获得用户时显示与用户关联的所有测验，而您最好在嵌入时使用，否则您将不得不在应用程序中加入该数据或使用$ lookup等加入数据，这可能会减慢您的应用程序。但要注意s-hunter提到的限制。

什么是更好的长期：在MongoDB中创建许多文档或使用嵌套数组创建更少的文档

2 个答案: