Executando verificação de segurança...
4

Porque simplicidade aparente cobra um preço. Só pessoas inexperientes acham que é simples.

NoSQL (termo ruim) é ótimo quando o problema encaixa perfeitamente nele. São raros os problemas que encaixam.

Tem problemas que são simples demais. Qualquer coisa que usar vai dar certo. Cada um vai cobrar um preço, mas pouco importa.

A maioria dos problemas complexos precisa de muita organização e cumprir certos objetivos, precisa de muito controle sobre as informações, e fácil se perder quando cria redundâncias, quando muita gente mexe. É aí que bancos de dados relacionais (se usa SQL ou não é outra questão) mostram seu valor. E os atuais conseguem fazer praticamente o mesmo que os NoSQL fazem quando é necessário em algum ponto. Você tem a opção, dá para usar de uma forma híbrida.

Essa aparente simplicidade se dá só em coisas muito simples onde os dados são praticamente só armazenados e nada mais se espera disso. Ou o modelo real dos dados é exatamente o modelo do banco de dados.

Não quero dar carteirada nisso, mas você acha que os profissionais mais experientes que fazem os sistemas mais complexos são todos trouxas por usar um banco de dados relacional na maioria dos projetos e só adotam NoSQL quando ele realmente é exigido e tem vantagem muito clara? Veja bem, estou falando de engenheiros estabelecidos, não influenciadores. Eu tenho acesso a muita gente muito boa, muito mais especialistas em bancos de dados, muitas vezes em qualquer tipo deles, gente com experiência brutal, com formação na área em alto nível, e todos preferem o relacional antes, e o NoSQL quando realmente ele se encaixa bem.

E até mesmo os maiores defensores de NoSQL falam que boa parte dos bancos nesse modelo, especialmente de documento, porque é o modelo onde as pessoas realmente usam errado, os outros quase sempre são bem indicados, especialmente em MongoDB (disparado o fornecedor mais usado nesse modelo), são modelados como se fosse relacional, mostrando claramente que o modelo deveria ter sido adotado. E só não gera grandes problemas porque é tão simples que não faz diferença. Quando não é, gera problema.

É frequente ver atrocidades usando NoSQL, porque a pessoa não vê a dificuldade que terá lá na frente quando os requisitos vão mudando. O relacional tem flexibilidade para atender esses casos.

Sem falar que essa facilidade de ficar mudando pode ser útil em algum ponto, mas vira pesadelo. É melhor ter coisas que precisam ser mais pensadas quando tem algo mais complexo. Ser fácil gera muita gambiarra. E nem é tão mais difícil assim mexer no relacional. Difícil é fazer dados redundantes para todo lado fazerem sentido em modelo de documento.

Veja mais e siga os links lá: https://pt.stackoverflow.com/q/274320/101 e https://pt.stackoverflow.com/q/576712/101.

E por coincidência, pouco depois de um postar isto, o Akita postou um vídeo sobre o assunto e conforma muito do que eu disse. Na verdade ele tem erros e discordo de várias coisas. Mas é assim mesmo. Outros vídeos dele também tem erros, conteúdos de todo mundo tem erros. E claro, o que eu faço também. Quem acha que não erra e que algumas pessoas não erram são os que cometem o pior dos erros. Isso não diminui o valor de coisa boa e a maioria das pessoas evoluirão muuuuuito vendo o vídeo. Um dia provavelmente faço um react e falo dos erros, nada grave. E aí alguém faz um com os erros que eu cometerei no meu.

Faz sentido para você?

Espero ter ajudado.


Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).

Carregando publicação patrocinada...
1

Muito bom, obrigado pelo seu comentário. Fez muito sentido para mim, puxa vida!

Vejo que você é muito ativo na comunidade, muito obrigado por isso @Maniero.

1

Considerando noSQL apenas como não relacional, existem casos mostrando que eles se encaixam em, praticamente, qualquer finalidade. E são bases grandes como hospitais, bancos, etc. do tipo bilhões de dados/transações anuais (teria que pesquisar as mensais) . Vamos ignorar os modismos tipo mongo, etc. Se existem sistemas comerciais (e que não são baratos) existe uma procura e as necessidades devem ser atendidas. Como exemplos, posso citar a Intersystem, Epic, etc..

Acho que os profissionais mais experientes também seguem o mainstream. Qualquer problema, é mais fácil colocar a dúvida em um site qualquer e receber uma resposta em uma hora ou um dia. Também tem o aspecto mão de obra. É mais fácil de conseguir e mais barato. Mas não significa que eles estão certos.

A própria SAP estava trabalhando em um modelo não relacional. Por divergências de visão, o desenvolvedor principal saiu e abriu o código criando o ArcadeDB.

Nesse exemplo é possível ver a comparação entre o diagrama de um relacional e um hierárquico. Sim, a diferença é gigante e o relacional necessita de um engenheiro. Esse exemplo faz parte do VistA. São 180 serviços entre clínicos, financeiros e administrativos, 9 milhões de pacientes (dados da página) e usados por 180.000 médicos. Alergias, receitas, históricos, exames, imagens, etc., para esse monte de gente não é pouca coisa. Entre outros, pode rodar no YottaDB. Falando em YottaDB, no dia 22/06/3023, eles publicaram este artigo: Connect Microsoft Analytics and Business Intelligence Tools to Octo - YottaDB.

Considerando alguém que teve um TK82-C (eu também tive) BD não relacional é do tempo em que a nossa vó andava de skate. Mais precisamente em 1966 no Massachusetts General Hospital.

A minha opinião é que, dependendo do escolhido, serve para tudo. Se o VistA não for parâmetro, não sei o que pode ser.