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

Banco de dados SQL ou NoSQL?

SQL ou NoSQL?

Eu estava estudando e estava pensando o seguinte:
  • DynamoDB

  • MongoDB

    Esses dois bancos são exemplos que podemos ter toda a construção das tabelas para o sistema rodar da maneiro como você precisa e se aparecer coisas de "ultima hora", idéias novas, a complexibilidade de fazer as mudanças, adições é muito mais tranquila ao meu ver.

    Se você com o NoSQL pode ter a construção das tabelas na sua mão e sem os problemas de ficar 'interligando' elas e gerando problemas futuros e complexibilidade.

Por que usar o SQL e deixar tudo mais complexo?

Carregando publicação patrocinada...
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).

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.

2

A resposta do @maniero é completíssima!!!

Um caso de uso:

  • Precisávamos guardar uma parte dos históricos de procedimentos industriais que não podiam ser alterados. Essa parte correspondia a um "questionário" e precisavam ser basicamente uma linha do tempo, um "commit", imutável, mesmo se futuramente o "questionátio" mudasse, na linha do tempo deveríamos ter a pergunta e a resposta do usuário naquele momento. Foi decidido então usar um banco não relacional pra isso, e que no final foi implementado no DynamoDB da AWS.

Só uma observação: noSQL significa not only SQL e não no SQL, porque bancos não relacionais podem ou não ter SQL, por isso o not only (não apenas) SQL.

2

Esse é um exemplo, tem vários outros. Mas são sempre casos mais específicos, não costuma ser bom para modelar uma aplicação inteira que fecha todos os aspectos de uma empresa. Nos links que eu passei tem uma listinha de exemplos.

O termo passou ser not only porque alguém notou que no não fazia sentido. No internado até hoje todo mundo escreve NoSQL e não NOSQL. Várias NoSQL usam SQL :D Por isso tiveram que mudar o significado. Tudo isso começou como uma enorme gambiarra, desde o termo. Aí tiveram que ajambrar.

Já é um enorme problema ter tantos modelos sendo chamados de NoSQL, isso causa entendimento errado. E para reforçar oque eu não deixei claro, o problema é o modelo de documento. Os outros modelos são bem menos usados e quase sempre adotam quando faz sentido e que o relacional não encaixa bem.

As pessoas abusam do modelo de documento (em alguns casos, mas bem mais raro, do chave-valor) e o adotam para algo que precisa de relacional. Provavelmente MongoDB tem um mercado 20 ou 30 vezes maior do que deveria ter.

De fato a moda trouxe umas coisas interessantes, tanto que os principais fornecedores de relacionais copiaram e colocaram essas novas features no relacional. Não é a mesma coisa, mas boa parte do que veio no modelo de documento dá para fazer no relacional, ao mesmo tempo.

Para usar todas as vantagens do modelo de documento, e a maioria dos usos reais dele não usam, por isso parece simples, realmente precisa de um produto dedicado, mas aí tem que abrir mão de algumas coisas que só o relacional consegue dar, e boa parte dos problemas existem e não podem abrir mão. E para conseguir as duas coisas é necessário praticamente reproduzir o banco de dados na aplicação, fazendo que perca a vantagem.

Então, novamente, tem casos que ele encaixa, e isso faz sentido, e tem muitos, mas ainda é uma minoria onde ele é bem útil. Que bom que inventaram, que ruim que a sociedade sempre abusa de novidades.

Um motivo extra para evitar é que o principal fornecedor mente muito, e influenciadores que falam dele fazem isso também. Quando precisa fazer isso já é um motivo político para se afastar.Se só falassem a verdade ele ainda seria adotado, mas não tanto quanto é.

0