sql - Mongodb 用于具有多对多关系的项目

Question

我正开始着手一个学习后端开发和一些前端开发的项目。为此，我想围绕 cooking 食谱创建一个项目。计划是创建一个管理 REST API，稍后将由自定义 CMS 使用它来创建、编辑、删除……食谱和一个用于移动应用程序的公共(public) API，您的用户可以在其中发现 cooking 食谱。简单起见，我考虑过选择 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 数据库之间产生显着的性能/成本差异吗？举个例子，如果我有一个包含 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.

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

在一些相关作者更新之后，您可以发出 recipes.updateMany({"author.id": authorId}, { $set: { author: author.profile}})

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

作者集合还可以包含最近 10 个食谱的列表，例如只有标题和日期......

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

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