I'm at the beginning of starting a project for learning backend development with a bit of frontend development. For that, I wanted to create a project around cooking recipes. The plan was to create an admin REST API that would be later used by a custom CMS to create, edit, delete,... recipes and a public api for a mobile app where your users can discover cooking recipes. Simplicity wise, I thought about choosing Mongodb as the database. While creating a Mongodb schema, I came up with this idea:
// 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,
}
My goal with this structure is to get the ingredients and the authors seperate from the recipes in order to update them independently. So, for example, when I edit my "tomato" ingredient, all recipes that contain this ingredient get updated too, in the sense that they only contain the ids of the ingredients. The same goes for the author. Now I'm asking myself if this kind of structure isn't more suited to a sql database. Would this structure make any significant performance/cost difference between a sql and a nosql/mongodb database? Just as an example, if I had a recipe that contains 20 ingredients, wouldn't that be 20(Ingredients) + 1 (author) + 1 (recipe itself) = 22 documents reads to get a whole recipe(is sql much faster here)? Is that fast enough or does that even make sense cost/ performance wise?
And one last question: how many concurrent connections would be possible with a Mongodb database?
My goal with this structure is to get the ingredients and the authors seperate from the recipes in order to update them independently.
That does not exclude the option to keep the data embedded in the recipes collection. You can keep a separate authors and ingredients collections AND also embed the fields needed in the recipe doc.
After some relevant author update you can issue recipes.updateMany({"author.id": authorId}, { $set: { author: author.profile}})
The idea is that author is not going to change very frequently, or at least the relevant data for recipes (basic profile info excluding birthdate, address, etc).
Also the authors collection can include a list of the last 10 recipes, for example with only title, and date,...
And one last question: how many concurrent connections would be possible with a Mongodb database?
No need to worry about that, it can handle as many as you need by adding hardware.