He usado MongoDB (y he probado los adaptadores MongoMapper y Mongoid con Rails) desde hace unos meses. Estaba profundamente atrincherado en SQL. Aquí están mis observaciones:
- La falta de un esquema y las migraciones no significa que reciba un almuerzo gratis. El código de su aplicación tendrá que llevar la lógica y las restricciones de los esquemas SQL. Tendrás que ser mucho más disciplinado para migrar manualmente los datos, p. cuando cambia el nombre de un atributo, o bien su código de aplicación tiene que tratar con múltiples nombres para la misma cosa (en este ejemplo). Esto podría conducir fácilmente a una gran cantidad de basura en la base de datos y/o errores desconocidos. MongoDB es genial porque no tienes que definir a priori qué cosas vas a almacenar, y puedes poner matrices enteras y jerarquías de objetos en cualquier atributo. De alguna manera, la facilidad de uso ofrece mucha menos seguridad, y creo que todavía estamos desarrollando muchas de las mejores prácticas sobre cómo evitar acumular muchas deudas técnicas aquí.
- Sin uniones: eso significa que debe conocer los patrones de acceso a sus datos (al menos los que deben ser escalables) cuando diseña sus colecciones.
- Sin transacciones: esto abre el riesgo de condiciones de carrera si los mismos registros en una colección son actualizables a partir de solicitudes simultáneas. Para las actualizaciones de colección única hay operaciones atómicas, y Mongoid las respalda y utiliza particularmente (pero no MongoMapper).
- 16 MB de límite de registro para cualquier registro. A diferencia de
text campos en SQL que pueden tomar contenido de tamaño arbitrario, MongoDB tiene un límite estricto de 16 MB para cualquier registro. Esto vale la pena considerarlo mientras planifica almacenar, p. matrices grandes, jerarquías de objetos, etc.
por favor haga wiki de la comunidad, o que se cerrará rápidamente –