Mongodb 对于具有多对多关系的项目

Question

我正开始着手学习后端开发和一些前端开发的项目。为此，我想围绕烹饪食谱创建一个项目。计划是创建一个管理员 REST API，稍后将由自定义 CMS 使用它来创建、编辑、删除...食谱和一个 public api 用于移动应用程序，其中您的用户可以发现烹饪食谱。简单起见，我考虑过选择 Mongodb 作为数据库。在创建 Mongodb 模式时，我想到了这个想法：

三个主要合集

// Recipes (SKETCH!)
{
 id: ObjectId,
 title: {
  en: string,  // Multiple languages
  de: string,
  fr: string,
 },
 description: {
  en: string,  // Multiple languages
  de: string,
  fr: string,
 },
 author: ObjectId, // Id of the author inside the authors collection
 imageUrl: string,
 ...
 ingredients: 
[
 //Ids of the ingredients inside the ingredients collection
 {
  id: ObjectId,
  amount: number,
 },
{
  id: ObjectId,
  amount: number,
 }
 ...
],
 steps: {
  en: [],
  de: [],
  fr: []
 }
}

// Author (SKETCH!)
{
 id: ObjectId,
 name: string,
 imageUrl: string,
 description: {
  en: string, // multiple languages
  de: string,
  fr: string,
 }
}

// Ingredients (SKETCH!)
{
 id: ObjectId,
 name: {
  en: string,
  de: string,
  fr: string
 }
 imageUrl: string,
 // Based on 100g
 protein: number,
 carbs: number,
 calories: number,
}

我对这种结构的目标是将成分和作者从食谱中分离出来，以便独立更新它们。因此，例如，当我编辑我的“番茄”配料时，所有包含该配料的食谱也会更新，因为它们只包含配料的 ID。作者也是如此。现在我在问自己，这种结构是否更适合 sql 数据库。这种结构会在 sql 和 nosql/mongodb 数据库之间产生显着的 performance/cost 差异吗？举个例子，如果我有一个包含 20 种成分的食谱，那不是吗？ 20（成分）+ 1（作者）+ 1（食谱本身）= 22 份文件读取以获得整个食谱（这里 sql 快得多）？这是否足够快，或者甚至在成本/性能方面是否有意义？

最后一个问题：Mongodb 数据库可能有多少个并发连接？

Answer 1

My goal with this structure is to get the ingredients and the authors seperate from the recipes in order to update them independently.

这不排除将数据嵌入食谱的选项 collection。您可以保留单独的作者和配料 collection，还可以在食谱文档中嵌入所需的字段。

一些相关的作者更新后你可以发布recipes.updateMany({"author.id": authorId}, { $set: { author: author.profile}})

作者的想法是不会经常更改，或者至少不会更改食谱的相关数据（基本个人资料信息，不包括生日、地址等）。

此外，作者 collection 可以包括最近 10 个食谱的列表，例如只有标题和日期，...

And one last question: how many concurrent connections would be possible with a Mongodb database?

不用担心，它可以通过添加硬件来处理您需要的数量。

Mongodb 对于具有多对多关系的项目

Mongodb for projects with many to many relationships

sql

mongodb

mongodb-query