Estoy comenzando un proyecto para aprender desarrollo backend con un poco de desarrollo frontend. Para eso, quise crear un proyecto en torno a recetas de cocina. El plan era crear una API REST de administración que luego usaría un CMS personalizado para crear, editar, eliminar,... recetas y una API pública para una aplicación móvil donde sus usuarios pueden descubrir recetas de cocina. En cuanto a la simplicidad, pensé en elegir Mongodb como base de datos. Mientras creaba un esquema Mongodb, se me ocurrió esta 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, }Mi objetivo con esta estructura es separar los ingredientes y los autores de las recetas para actualizarlos de forma independiente. Entonces, por ejemplo, cuando edito mi ingrediente "tomate", todas las recetas que contienen este ingrediente también se actualizan, en el sentido de que solo contienen las identificaciones de los ingredientes. Lo mismo ocurre con el autor. Ahora me pregunto si este tipo de estructura no es más adecuada para una base de datos sql. ¿Haría esta estructura alguna diferencia significativa de rendimiento/costo entre una base de datos sql y una base de datos nosql/mongodb? Solo como ejemplo, si tuviera una receta que contiene 20 ingredientes, ¿no serían 20 (ingredientes) + 1 (autor) + 1 (receta en sí) = 22 lecturas de documentos para obtener una receta completa (es sql mucho más rápido aquí) )? ¿Es eso lo suficientemente rápido o incluso tiene sentido en cuanto a costo/rendimiento?
Y una última pregunta: ¿cuántas conexiones simultáneas serían posibles con una base de datos Mongodb?
Mi objetivo con esta estructura es separar los ingredientes y los autores de las recetas para actualizarlos de forma independiente.
Eso no excluye la opción de mantener los datos incrustados en la colección de recetas. Puede mantener colecciones separadas de autores e ingredientes Y también incrustar los campos necesarios en el documento de la receta.
Después de alguna actualización relevante del autor, puede emitir recipes.updateMany({"author.id": authorId}, { $set: { author: author.profile}})
La idea es que el autor no cambie con mucha frecuencia, o al menos los datos relevantes para las recetas (información básica del perfil, excluyendo fecha de nacimiento, dirección, etc.).
Además, la colección de autores puede incluir una lista de las últimas 10 recetas, por ejemplo, con solo título y fecha,...
Y una última pregunta: ¿cuántas conexiones simultáneas serían posibles con una base de datos Mongodb?
No debe preocuparse por eso, puede manejar tantos como necesite agregando hardware.