Su aplicación es flexible o no tiene absolutamente nada que ver con el uso de "nosql", un "documento db" o un RDBMS adecuado. Nadie que use su aplicación se preocupará de ninguna manera.
Si necesita flexibilidad durante la codificación, debe buscar marcos, como ActiveRecord for Ruby, que pueden hacer que la interconexión de DB sea mucho más simple, genérica y poderosa. En ese nivel, puede obtener mucho más que solo cambiar la base de datos, e incluso puede volverse DB-agnóstico, lo que significa que puede cambiar la base de datos sin cambiar ningún código. De hecho, he encontrado ActiveRecord para aumentar mi productividad muchas veces aliviando de tedioso y propenso a error "código entremezclado con SQL".
De hecho, si cree que necesita una base de datos sin esquema, para datos críticos, está haciendo algo mal. Está poniendo su propia conveniencia sobre las necesidades críticas de los proyectos, o ignorando que no tendrá problemas más adelante. Tarde o temprano, la falta de consistencia te morderá el culo, ¡duro!
Siento que eres reacio a los RDBMS porque no estás tan cómodo con todos los jerga, la sintaxis y los principios sólidos de CS.
Créanme, si va a crear una aplicación de cualquier valor, cien veces es mejor aprender SQL, ACID y buenos principios de base de datos en primer lugar. Solo lee sobre lo básico y crea tu conocimiento desde donde estés ahora. Es lo mismo para todos y cada uno de nosotros, lleva tiempo, pero aprendes a hacer las cosas bien desde el principio.
Las herramientas de bajo nivel como MongoDB y su equivalente solo le proporcionan infinitamente más municiones para dispararse en el pie. Lo hacen parecer fácil. En realidad, sin embargo, dejan el trabajo duro para que usted, el programador, se encargue de él, mientras que un RDBMS se encargará de más de usted una vez que comprenda los conceptos básicos.
¿Por qué usar computadoras? Si desea más trabajo, puede volver al papel. El diseño será rápido y la implementación puede ser súper rápida. Hecho. Excepto que no será correcto, por supuesto.
En el mundo real, no podemos permitirnos ignorar la coherencia, el diseño de bases de datos y muchos más principios sólidos de CS. Por eso es una gran idea estudiarlos en primer lugar, y seguir aprendiendo más y más.
No compre en el bombo. Haga preguntas sobre MongoDB aquí, pero incluya que realmente necesita sus características. Con 25 años de experiencia informática, simplemente no lo compro. Si piensas creativamente, se puede hacer que un RDBMS haga lo que quieras, o se puede utilizar un marco para salvarte de errores y tiempo perdido.
Crear propiedades de ACID en MongoDB me parece más trabajo, y por experiencia, suena como un ejercicio inútil, en lugar de usar lo que ya está diseñado para esos propósitos.
¿Por qué quiere o necesita usar MongoDB? ¿Cuáles son los beneficios como los ves? ¿Por qué es decir, postgres no es el más adecuado para su aplicación? Algunas compañías (friendfeed) simplemente almacenan JSON en un RDBMS, dando un esquema flexible con los beneficios de ACID de un DB normal. –
También puede usar CouchDB, también es un documento db. – TTT
@Mark. Porque prefiero trabajar con objetos y objetos incrustados en objetos en lugar de tablas, columnas y filas. Me gusta el paradigma OOP más porque se ajusta al pensamiento humano. Los tipos de datos XML/JSON no pueden reemplazar eso. Es solo para almacenar estructuras pequeñas, no toda la estructura de la base de datos. –