Em 6 de novembro de 2015 10:13, Matheus Saraiva <matheus.sara...@gmail.com> escreveu: > Bem, lá vai a opinião de alguém bem menos experiente do que todos que > participaram desse off, aja vista que eu não sou dba, apenas dev.
Eu sou um misto de dba e dev, conheço pouco - ou nada - NoSQL e gostaria de exemplificar um caso real que acompanhei de perto. > Eu realmente não posso aqui debater a possibilidade de uma migração para > 100% NoSQL, visto que ainda sei pouco sobre esse método de armazenagem e > gerenciamento de dados. Eu acredito que posso dar um "pitaco". > Mas, hoje em dia ainda existem, e em quantidades razoáveis, grandes sistemas > rodando em tecnologias descontinuadas como cobol, dbase, dataflex, clipper, > etc. Algumas redes bancárias ainda hoje tem seus sistemas rodando em cobol. > A coisa ficou tão funcional, tão estável que eles não se atrevem a fazer uma > migração para uma solução relacional. Muitas destas tecnologias armazenavam informações sob o conceito de linhas e colunas, e, apesar de não incorporarem nativamente um SGBDR não podem ser consideradas NoSQL. Não é possível armazenar objetos complexos, como um objeto JSON repleto de atributos multivalorados em arrays sem ter uma definição prévia (quantos atributos, tipo de atributos, etc.). No caso do Cobol e Clipper (.DBF) é possível até executar instruções SQL SELECT sobre o conjunto de tabelas/arquivos, portanto, aproximam-se mais do modelo relacional do que NoSQL. > A questão que levanto é, se esse casos de uso, conseguem viver sem o modelo > relacional e ter soluções satisfatórias, mesmo usando tecnologias > descontinuadas à décadas. Por que, o NoSQL, na figura do mongoDB, casandra, > etc, que são soluções mais atuais e de desenvolvimento e comunidade ativos > não podem ser também usadas como único sgdb de forma satisfatória? As tecnologias antigas citadas anteriormente não chegam perto dos conceitos de NoSQL atuais. E, de fato, trabalhei para o HSBC há alguns anos. Lá pelo menos é usado SGBDR em tudo. A parte em Cobol puro é utilizada para aplicações críticas que demandam processamento "quase real" e depois todas as informações são exportadas e armazenadas em bancos relacionais (Oracle e Sybase ASE). Apesar de eu nunca ter trabalhado com NoSQL participei de um time de desenvolvimento para uma empresa que estava indo fundo em um projeto que, à exemplo do OP, queria mesclar NoSQL com SGBDR. Eu, obviamente, fiquei no "subtime" do SGBDR. O time de desenvolvedores (Java) por muito tempo ficou excitado com as novas possibilidades usando MongoDB, pouca demanda era repassada para a minha equipe e muitas justificativas de usar o MongoDB (como desempenho, facilidade de programação, etc.) eram dúbias (tudo era possível ser feito em SGBDR). Lembro-me bem de um programador que dizia que "trabalhar com NoSQL era tão fácil quanto abrir um arquivo texto e inserir informações neles". Eu muito questionei como estes dados seriam consistentes depois, como seriam feitas as consultas, como garantir que uma informação de uma entidade (ou objeto para eles) estaria realmente gravada no banco de dados. As respostas sempre eram as mesmas: isso a aplicação irá resolver, a aplicação precisa estar bem desenvolvida e bem testada. Passaram pelo menos 4 anos desde que este projeto começou e ainda não terminou. A complexidade tornou-se tão enorme que para criar um "módulo" simples, um CRUD, são necessários pelo menos 4 dias. Depois de milhares (senão milhões) de reais gastos, o projeto dá sinais de que será abandonado. E a integridade de informações? Bem, o mesmo programador me disse que é um inferno na terra, que depois de um certo número de registros (ops, objetos) armazenados as consultas NoSQL são enormes tratando diversos tipos de atributos que podem ou não existir, muito lixo é armazenado e também há o caso do "programa bem desenvolvido e bem testado" que nunca existe, trazendo muito mais dor de cabeça que benefícios. > Será as > soluções NoSQL atuais tão ruins assim que conseguem ser piores do que > tecnologias descontinuadas à várias décadas? Para transportes terrestres não vi nada mais eficiente que rodas sob os veículos para permitir a locomoção. O ponto que quero chegar é que existem tecnologias e conceitos tão maduros que não precisem ser recriados, apenas aperfeiçoados. Clipper, por exemplo, foi o predecessor do FoxPro e do Visual FoxPro que já utilizavam SGBDRs rudimentares nativamente (se não me engano até existia um plugin OraClipper para acessar bancos Oracle no Clipper Summer 87, mas já não lembro). Com todas as novas implementações dos SGBDRs permitindo o armazenamento de objetos JSON e dados complexos, não vejo motivo algum para usar NoSQL. Isso é modinha à exemplo do Cachè antigamente, que tinha até propaganda na Revista Info. Mas quem quiser tentar, vai fundo e compartilha a experiência! TIAGO J. ADAMI http://www.adamiworks.com @tiadami _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
