Voce ter toda a estrutura do teu modelo duplicada num banco de dados, com todas as suas gambiarras/mapeamento para que esta estrutura se encaixe ao modelo relacional.
Sim, assim como num modelo OO, um funcionario tem N dependentes e não N chaves estrangeiras apontando para dependentes. Quando voce guarda o seu funcionario, guarda junto com ele os seus dependentes.
Se voce estava se referindo a relacao entre funcionarios de cargos distinto, como o funcionario gerente e o funcionario operador, talvez então ele se encaixe no outro topico do kikolobo. Naquele em que diz que redundancia eh um problema. E nesse caso entao o uso do banco relacional seja mais efetivo.
no caso, eu não citei o Datastore da App Engine porque no post estou dizendo minha vivência no assunto. Nunca trabalhei com ele, desculpa.
Sobre migração de bancos de dados, diversos. É muito comum por exemplo no desenvolvimento de produtos, em que você precisa fazer adequações para que se encaixe à infra do cliente (sim, acontece).
André, agora, com relação à produtividade: de que maneira os bancos NoSQL aumentam a sua?
No caso, a produtividade não viria mais da adequação do seu modelo ao mecânismo de persistência que você adotou?
Concordo, mas como postei no outro comentario, esse caso se encaixa mais na necessidade de evitar dados duplicados. No exemplo de funcionario/cargos, acho que, a primeira vista, o modelo relacional atende melhor. Mas talvez estas sejam exceções e não regras.
Será que tambem essas situações de transação entre documentos não são mais excepcionais do que podem parecer a principio? Transacao bancaria é um exemplo clássico que pede controle rigoroso de transação, você citou mais uma com a qual teve experiência. Será que há tantas assim que de tão importante não poderiam ser ficar confiadas apenas a aplicação?
A mim parece, assim como o quesito de integridade referencial, que os bancos relacionais seriam usados nas exceções e não nas regras.
Só pra situar quem chega ao tópico. Tudo que eu falo é baseado apenas no que tenho lido, não tenho a menor experiência com bancos NoSQL, embora esteja querendo dar uma olhada “mais de perto”.
Oi YvGa, interessantíssimo o seu post. Quero entender melhor isto. Me explica duas coisas:
Neste caso, o problema não seria do modelo relacional, mas sim de quem fez a análise errada e optou pelo modelo equivocado? O peso aí estaria em quem fez a escolha errada, não?
Um outro ponto que eu acho interessante é o seguinte: vejo muita gente cometendo o erro de no modelo documental ter documentos gigantescos cuja extração e manutenção acaba ficando bastante cara.
Nestes casos, o sujeito acaba quebrando o documento em mais de um e em seguida linkando-os, como o faria no modelo relacional.
Nesta situação, não seria mais negócio ir para o modelo relacional? Qual o limite do documental na sua opinião?
Para enriquecer a discussão, sugiro a leitura deste artigo: “The Cost of Data”.
É muito interessante, porque trata justamente do custo da informação semi definida (aonde entra o NoSQL e sai o SQL).
Basicamente o autor mostra que informação não estruturada vale à pena ser mantida como tal e que a tipificação normalmente só adiciona custo desnecessário e acréscimo de complexidade.
Link: http://queue.acm.org/detail.cfm?id=1103843
De novo, acho que não sejam situações tão excepcionais assim estas nas quais é preciso lidar com mais de um documento. Em sistemas complexos, em que exista a integração de entidades entre si, estas acabam ocorrendo.
Além disto, é importante mencionar também que indiferente de ser com um ou dois documentos, outro ponto importante a ser lembrado é o da isolabilidade. Será que conseguimos garantir sempre a isolabilidade no modelo NoSQL (eu sei que cada caso é um)? Este é um ponto que a gente tem de ter em mente sempre.
Tudo bem: pode ser raro mais de um cliente acessando e modificando o mesmo documento, porém quando você para pra pensar em uma empresa composta por departamentos, cada qual com mais de um funcionário - que normalmente estão lidando com a mesma coisa - o negócio se torna bem mais comum.
[quote=kicolobo]Sobre migração de bancos de dados, diversos. É muito comum por exemplo no desenvolvimento de produtos, em que você precisa fazer adequações para que se encaixe à infra do cliente (sim, acontece).
[/quote]
Concordo nesse ponto, eu já precisei fazer ao menos tres grandes migrações de bases de dados por que o cliente já possuia licença de outra empresa. E em tres empresas diferentes. Então acho que esse é um ponto a ser considerado sim, na adoção ou não de NoSQL.
[quote=kicolobo]
André, agora, com relação à produtividade: de que maneira os bancos NoSQL aumentam a sua?
No caso, a produtividade não viria mais da adequação do seu modelo ao mecânismo de persistência que você adotou?[/quote]
Mas é essa adequação o grande problema dos bancos relacionais. É dificil, trabalhosa, manual e com workarounds (como mapeamento de heranca, lazy loading por conta de chaves estrangeiras, utilizar linguagens quase sql ao invés de sql puro, entre outras gamiarritas mas).
Na realidade, o grande ganho que o NoSQL trouxe na minha opinião foi o fato de ter nos acordado pro fato de que estávamos usando o modelo relacional como a solução para todos os problemas, o que, para qualquer tecnologia, não é verdade nunca.
Eu sou a favor de uma abordagem mais híbrida, na qual mais de um modelo (relacional ou não) sejam aplicados, um em cada caso. Assim a gente evita transformar um modelo específico, por exemplo, o documental, no “relacional de amanhã”, entende?
[quote=YvGa][quote=kicolobo]Sobre migração de bancos de dados, diversos. É muito comum por exemplo no desenvolvimento de produtos, em que você precisa fazer adequações para que se encaixe à infra do cliente (sim, acontece).
[/quote]
Concordo nesse ponto, eu já precisei fazer menos tres grandes migrações de bases de dados por que o cliente já possuia licença de outra empresa. E em tres empresas diferentes. Então acho que esse é um ponto a ser considerado sim, na adoção ou não de NoSQL.
[/quote]
Srs, uma coisa é IMPLANTAR um produto em diversos clientes que usam fornecedores de banco diferentes. Outra coisa é MIGRAR um banco pq um cliente, a partir de agora, quer em banco X e não mais em banco Y. A segunda situação ocorre com bastante raridade.
Seria ingenuidade acreditar que vc não tem que lidar com vendor lock-in, mesmo sendo migração SQL -> SQL.
[quote=andre_salvati][quote=YvGa][quote=kicolobo]Sobre migração de bancos de dados, diversos. É muito comum por exemplo no desenvolvimento de produtos, em que você precisa fazer adequações para que se encaixe à infra do cliente (sim, acontece).
[/quote]
Concordo nesse ponto, eu já precisei fazer menos tres grandes migrações de bases de dados por que o cliente já possuia licença de outra empresa. E em tres empresas diferentes. Então acho que esse é um ponto a ser considerado sim, na adoção ou não de NoSQL.
[/quote]
Srs, uma coisa é IMPLANTAR um produto em diversos clientes que usam fornecedores de banco diferentes. Outra coisa é MIGRAR um banco pq um cliente, a partir de agora, quer em banco X e não mais em banco Y. A segunda situação ocorre com bastante raridade.
Seria ingenuidade acreditar que vc não tem que lidar com vendor lock-in, mesmo sendo migração SQL -> SQL.[/quote]
Oi André, discordo. A segunda alternativa ocorre com bastante frequencia também.
Anos atrás, por exemplo, era muito comum o pessoal que precisava gastar bastante com licença em Oracle fazer migrações para o MySQL, PostgreSQL, etc. Eu mesmo cheguei a participar de algumas situações assim.
Porém, nesta discussão, até agora ninguém falou da segunda opção, mas mais da primeira mesmo. Que o padrão SQL não é igual em todos os bancos, isto todo mundo já sabe, prova disto são os dialetos no Hibernate, porém é uma situação mais gerenciável do que a que encontramos no ambiente NoSQL.
no caso, eu não citei o Datastore da App Engine porque no post estou dizendo minha vivência no assunto. Nunca trabalhei com ele, desculpa.
[/quote]
Quando o assunto é NoSQL, qq generalização é falha.
[quote=kicolobo]
André, agora, com relação à produtividade: de que maneira os bancos NoSQL aumentam a sua?
No caso, a produtividade não viria mais da adequação do seu modelo ao mecânismo de persistência que você adotou?[/quote]
O principal motivo é pq o banco é schema free. Não preciso me preocupar com inclusões de campos em tabelas, migrações de bd, etc. Isso libera tempo e recursos para focarmos em melhorias de funcionalidade da app.
Dá uma olhada na primeira parte dessa entrevista, o carinha explica bem isso:
BREAKING NEWS
Posso só dar um comentário simples? É que falaram de redes sociais… no último QCon SP teve uma palestra sobre o Facebook… e aí foi dito que eles usavam MySql em uma gambiarra para fingir que era NoSql (concatenando todos os campos numa stringona)
pronto, podem voltar a falar de migração. Aliais, acrescentando um ponto de vista:
uma vez numa empresa tive que migrar de um banco MySql para um Oracle, porque o cliente quis. Motivo? Funcionários de TI do cliente chegaram a conclusão que seria mais seguro (ahn?? com base no que? precisam assim de tanto grau de segurança?) e houve algumas semanas de trabalho por causa de registros (imagina, usavam windows server. Já viu né?) e boa parte do trabalho foi por causa da ferramenta de ORM mesmo).
Bacana. Mas…daria trabalho, dependendo de como você tinha trabalhado antes e como vai trabalhar depois, de qualquer forma. Então acho que não é válido a idéia de que “NoSql dá trabalho para migrar”. Vai dar trabalho. Tudo. Okay, pode dar até um pouco de trabalho a mais, mas, acho que nem vai ocorrer mudanças de banco a toda hora. Imagino que se você está usando NoSql você sabe melhor o que está fazendo e para o que vai precisar, logo não vai ter problemas como os que eu tive em que o cliente achou mais seguro e quis mudar. Creio que você vai ter mais controle da situação, não?
[quote=MayogaX]BREAKING NEWS
Posso só dar um comentário simples? É que falaram de redes sociais… no último QCon SP teve uma palestra sobre o Facebook… e aí foi dito que eles usavam MySql em uma gambiarra para fingir que era NoSql (concatenando todos os campos numa stringona)
[/quote]
Twitter e Google tb usam NoSQL. Engraçado, os que mais escalam…
Isso mesmo. Até para atualizar uma app é infinitamente mais fácil com o NoSQL devido às características q mencionei no post anterior.
Mas ai que tá André e Mayumi, migração é só um detalhe na hora de escolher.
É um entre diversos critérios que o arquiteto/desenvolvedor/whatever tem de levar em consideração no momento de escolha da base.
Mas aí eu te cutuco de novo André: você acha que todo modelo pode ser usado pelo documental então? Neste caso, você não estaria repetindo o erro de estar usando uma única solução para tudo?
Em quais casos o documental pularia fora na sua opinião? Em que situações o relacional seria uma boa pra você?
[quote=kicolobo]
Mas aí eu te cutuco de novo André: você acha que todo modelo pode ser usado pelo documental então? Neste caso, você não estaria repetindo o erro de estar usando uma única solução para tudo?
Em quais casos o documental pularia fora na sua opinião? Em que situações o relacional seria uma boa pra você?[/quote]
Não há bala de prata em desenvolvimento de SW.
Cada caso é um caso e deve ser analisado detalhamente, o que fica difícil em um fórum de discussões.
Só discordo de receitinhas de bolo para tomada de decisões.
[quote=andre_salvati][quote=kicolobo]
Mas aí eu te cutuco de novo André: você acha que todo modelo pode ser usado pelo documental então? Neste caso, você não estaria repetindo o erro de estar usando uma única solução para tudo?
Em quais casos o documental pularia fora na sua opinião? Em que situações o relacional seria uma boa pra você?[/quote]
Não há bala de prata em desenvolvimento de SW.
Cada caso é um caso e deve ser analisado detalhamente, o que fica difícil em um fórum de discussões.
Só discordo de receitinhas de bolo para tomada de decisões.[/quote]
André, que não há bala de prata, isto todo mundo já sabe né?
Vou melhorar minha pergunta: na sua opinião/experiência, já topou com situações em que o modelo documental não fosse bacana? Este tipo de experiência seria muito bacana pra enriquecer a discussão. NO entanto, apesar de cada caso ser um caso, sempre há alguma diretriz que você leva em consideração na sua escolha não?
