Eu venho tentando há algum tempo colocar algumas coisas 'legais' que tenho lido sobre noSQL (couchDB, mongoDB, Redis ...) nos últimos anos para uso prático.

Estou bastante acostumado a escrever aplicativos com o Django e comecei a usar o Play! quando Java é a única opção de implantação aceitável (e também a aproveita). Ambos têm módulos para trabalhar, por exemplo, com MongoDB e django também tem nonrel. Mas nunca senti a necessidade do noSQL.

té que finalmente encontrei o que considerava um bom caso de uso para armazenamento orientado a documentos, como o MongoD

Use Case

Digamos que tenhamos que gerenciar pedidos e acompanhamento (qualquer que seja) de alguns itens complexos. Os itens podem ter muitas propriedades diferentes, por exemplo. simplificando demais, poderíamos ter:

uma geladeira que pode ter uma ou duas portas, da classe A, B ou C, uma cor de superfíciestandalone ou embutido um forno que pode ter: gás ou eletricidade ou ambos auto limpeza ou nãostandalone ou embutido Solução SQL / ORM

omo você pode ver, cada objeto pode ter várias propriedades que podem ser restringidas por tip

No meu RDBMS habitual, através de um ORM, eu definia um modelo de "produto" e depois herdava dois modelos, um refrigerador e um forno. Se um Fridge receber mais uma propriedade algum tempo depois, modifico o modelo - e, como tal, o esquema -, executo uma migração e adiciono uma colun

noSQL solutions

s soluções @noSQL em que consigo pensar são:

sando RDF (com algo comoVirtuos ou criar meu próprio armazenamento triplo simplificado) usando um banco de dados orientado a documentos como o MongoDBO problem

Mas Não consigo entender o quão diferente (mais fácil) o desenvolvimento seria pragmaticamente esta alternando para uma solução noSQL ainda usando a estrutura ORM com o adaptador correto (especialmente com DODB

Digamos que estou usando o Django com MongoDB através do mongodb-engin

Ainda estou usando o mesmo ORM, por isso ainda descrevo esses objetos como modelos, listando todas as propriedades. O ORM está, portanto, fazendo exatamente o mesmo trabalho! O custo de produzir uma migração se o modelo mudar é muito limitado com um ORM (em particular com algo como o Sul), nada exigindo o aprendizado de uma nova tecnologia por si s

Pode haver / outras / vantagens em um DODB e algumas específicas no MongoDB (escalabilidade, processamento de dados, talvez desempenho), mas ... e o caso de uso exato e o problema que estou descrevendo?

Provavelmente estou perdendo um ponto, então aqui vem a (s) verdadeira (s) questão (s):

Para este caso de uso específico:

esse exemplo é bom ou ruim para o DODB (você tem um bom)? faria sentido combinar um ORM para itens básicos (Usuários, Pedidos) e uso de noSQLse ORM para objetos complexos, existe um motivo convincente para mudar completamente para o noSQL ou devo ficar com o ORM / SQL padrã

Entendo que responder a essas perguntas pode ser parcialmente subjetivo, para que você possa assumir um conhecimento perfeito da teoria noSQL e SQL e do ORM de ações; existência de boas pontes de ORMs de ações para noSQL DB. Vamos supor que estamos falando sobre esse caso de uso com o MongoDB como alternativa noSQL.

Mas existe uma pergunta mais geral - que é a questão central deste post da SO:

ão é um bom ORM (como JPA, ActiveRecord ou Django) tornando o noSQL e, em particular, bancos de dados orientados a documentos de pouco us ... e vale a pena usar noSQL com um ORM 'clássico'?

"pouco uso" do ponto de vista de programação e manutenção, desempenho e critérios semelhantes são uma questão diferente e exigiriam uma comparação precisa de produto para produto

[editar

O que também estou tentando entender é se não seria melhor deixar de usar um ORM ao mudar para noSQL. Seria bom ter modelos mais "dinâmicos", por exemplo. Eu poderia ter uma tabela descrevendo o que a geladeira e o forno models are (campos), e os modelos Fridge e Oven no código poderiam construir suas visualizações dinamicamente (formulários para edição e listagens para exibição

Perguntas relacionadas

[editar: estão aqui para mostrar minha pesquisa, mas também para esclarecer que o que estou perguntando não é genérico sobre noSQL vs. SQL

m ORM é redundante com uma API NoSQ: semelhante! mas estou tentando entender por que a maioria das estruturas (veja acima) está fornecendo acesso noSQL por meio de seus ORMs. É uma boa ideia ou não?por que o uso de um ORM com NoSql (como MongoDB): mais específico que o anterior, mas ainda é o contrário. Estou argumentando queORMs tornam o noSQL inútil, e não o contrário!Quando substituir RDBMS / ORM por NoSQLuando usar o MongoDB ou outros sistemas de banco de dados orientados a documentohttps: //softwareengineering.stackexchange.com/questions/54373/when-would-someone-use-mongodb-or-similar-over-traditional-rdm

EDITA E links:

Siena: uma API de persistência para Java inspirada no armazenamento de dados Python do Google App Engine, tentando estabelecer uma ponte entre os mundos SQL e NoSQ minimongo: interface leve, sem esquema e orientada a objetos Pythonic para o MongoDB