Si quiere 'minimizar impacto', querrá crear una base de datos en MongoDB, la que tiene en SQL. Como no hay uniones en la base de datos, deberá hacer varias lecturas para completar su consulta. En sí mismo no es tan malo porque MongoDB es realmente rápido, pero obviamente tiene otros problemas (concurrencia, etc.).
Si, sin embargo, desea pasar totalmente a la forma NOSQL de hacer cosas que probablemente no podrá 'minimizar el impacto', tendrá que hacer cambios sustanciales en la forma de almacenar contenido, la forma de acceder a él y la forma de actualizarlo.
Almacenamiento: Es probable que cree documentos en su base de datos que estén desnormalizados y estén mucho más cerca de 'ViewModels' que de 'Modelos'. Por ejemplo, puede almacenar un recuento de registros secundarios en un registro principal para que pueda visualizarlo sin tener que cargarlos o contarlos.
Acceso: Puede terminar usando Map-Reduce para algunas consultas a su base de datos, que es una mentalidad muy diferente de una consulta tradicional.
Actualizaciones: Lo más probable es que su acercamiento a la actualización será diferente con el fin de tomar ventaja de las muchas funciones de actualización MongoDB de grano fino como $inc
. En lugar de publicar un modelo de vista grande y luego aplicarlo a su modelo y luego actualizar la base de datos, en su lugar podría proporcionar una devolución de llamada Ajax mucho más precisa que actualice un solo valor. Eche un vistazo a CQRS para obtener más ideas sobre cómo pensar en modelos para actualizaciones y consultas.
¡Gran explicación! Gracias – marvelTracker