He estado intentando durante algún tiempo poner en práctica algunas cosas 'interesantes' que he estado leyendo sobre noSQL (couchDB, mongoDB, Redis ...) en los últimos años.

Estoy bastante acostumbrado a escribir aplicaciones con Django, ¡y comencé a usar Play! cuando Java es la única opción de implementación aceptable (y también la disfruta). Ambos tienen módulos para trabajar, por ejemplo, con MongoDB, y django también tiene nonrel. Pero nunca sentí la necesidad de noSQL.

asta que finalmente encontré lo que pensé que era un buen caso de uso para el almacenamiento orientado a documentos, como MongoDB.

Utilizar caso

Digamos que tenemos que gestionar el pedido y el seguimiento (lo que sea) de algunos elementos complejos. Los artículos pueden tener muchas propiedades diferentes, por ejemplo. simplificando demasiado podríamos tener:

a Nevera que puede tener una o dos puertas,be de clase A, B o C, un color de superficiestandalone o incorporadoan Horno que puede tener:gas o electricidad o ambas auto limpieza o nostandalone o incorporado Solución SQL / ORM

omo puede ver, cada objeto puede tener varias propiedades que pueden estar restringidas por tipo.

En mi RDBMS habitual a través de un ORM, iría con la definición de un modelo de "producto", luego heredaría dos modelos, un refrigerador y un horno. Si un refrigerador obtiene una propiedad más algún tiempo después, modifico el modelo, y como tal, el esquema, ejecuto una migración y agrego una columna.

noSQL solutions

as soluciones de @noSQL que se me ocurren son:

using RDF (con algo comoVirtuos o construyendo mi propio almacenamiento de triples simplificado)usando una base de datos orientada a documentos como MongoDBEl problem

Peroo logro entender cuán diferente (más fácil) sería el desarroll pragmáticamente be cambiar a una solución noSQL que todavía utiliza el marco ORM con el adaptador correcto (especialmente con DODB).

Digamos que estoy usando Django con MongoDB a través de mongodb-engine.

Todavía estoy usando el mismo ORM, por lo que sigo describiendo esos objetos como modelos, enumerando todas las propiedades. ¡El ORM está haciendo exactamente el mismo trabajo! El costo de producir una migración si el modelo cambia es muy limitado con un ORM (en particular con algo como South), nada que requiera aprender una nueva tecnología por sí mismo.

Podría haber / otras / ventajas para un DODB, y algunas específicas para MongoDB (escalabilidad, procesamiento de datos, tal vez rendimiento) pero ... ¿qué pasa con el caso de uso exacto y el problema que estoy describiendo?

Probablemente me estoy perdiendo un punto, así que aquí vienen las preguntas reales:

Para este caso de uso específico:

es este ejemplo bueno o malo para DODB (¿tienes uno bueno?)Tendría sentido combinar un ORM para cosas básicas (usuarios, pedidos) y el uso de noSQLsi ORM para objetos complejos, ¿hay alguna razón convincente para cambiar a noSQL por completo, o debería quedarme con el stock ORM / SQL?

Entiendo que responder estas preguntas podría ser parcialmente subjetivo, por lo que puede asumir un conocimiento perfecto de la teoría noSQL y SQL, y ORM de valores; existencia de buenos puentes desde ORMs de stock a noSQL DB. Supongamos que estamos hablando de este caso de uso con MongoDB como alternativa noSQL.

Pero hay una pregunta más general, que es la pregunta central de esta publicación SO:

¿No es un buen ORM (como JPA, ActiveRecord o el de Django) que hace que SQL y en particular las bases de datos orientadas a documentos sean de poca utilidad? ... ¿y vale la pena usar noSQL con un ORM 'clásico'?

("poco uso" desde el punto de vista de programación y mantenimiento, el rendimiento y criterios similares son un asunto diferente y requerirían una comparación precisa de producto a producto)

[editar

Lo que también estoy tratando de entender es si no sería mejor dejar de usar un ORM al cambiar a noSQL. Sería bueno tener modelos más "dinámicos", por ejemplo. Podría tener una tabla que describa lo que el refrigerador y el horno modelos are (campos), y los modelos Fridge and Oven en el código podrían construir sus vistas dinámicamente (formularios para editar y listados para mostrar).

Preguntas relacionadas

[editar: están aquí para mostrar mi investigación, pero también para aclarar que lo que pido no es genérico sobre noSQL vs. SQL

¿Es un ORM redundante con una API NoSQL?: similar! pero estoy tratando de ver por qué la mayoría de los frameworks (ver arriba) están proporcionando acceso noSQL a través de sus ORM. ¿Es una buena idea o no?por qué el uso de un ORM con NoSql (como MongoDB): más específico que el anterior, pero sigue siendo al revés. Estoy argumentando queORMs hacen que noSQL sea inútil, en lugar de al revés!Cuando reemplazar RDBMS / ORM con NoSQL ¿Cuándo utilizar MongoDB u otros sistemas de bases de datos orientados a documentos?https: //softwareengineering.stackexchange.com/questions/54373/when-would-someone-use-mongodb-or-similar-over-traditional-rdm

EDITA Y enlaces:

Siena: una API de persistencia para Java inspirada en el almacén de datos de Python de Google App Engine que intenta trazar un puente entre los mundos SQL y NoSQL. minimongo: interfaz ligera, sin esquema, Pythonic orientada a objetos para MongoDB