Uma das perguntas que eu mais recebo, é sobre quando usar um banco de dados relacional e quando usar um banco de dados NoSQL, por isso resolvi começar 2020, com alguns posts sobre esta questão.

Os posts serão semanais, e este é o primeiro da série. Vamos começar conversando sobre os bancos de dados relacionais.

Os bancos de dados relacionais

Antes de começar “o rolê” prometo deixar as minhas paixões de lado, e te peço para deixar as suas também… Vamos falar de fatos e características, e quem sabe no final da série podemos conversar sobre as paixões…

Lembre-se que os bancos de dados relacionais existem há quase 40 anos e deram muito certo!

Senta que lá vem a história (por favor… não deduzam a minha idade!)

Há 40 anos atrás o hardware era caro, de forma que o armazenamento de dados precisava ser pensado para minimizar o custo dos sistemas. Neste cenário as “Formas Normais” (lindas) tem total sentido, porque um dos motivos para elas existirem é minimizar a redundância, porque a redundância tinha um custo alto!

Outras características fofas dos bancos de dados relacionais, eles usam linguagens baseadas no padrão SQL para administração e manipulação dos dados, e possuem suporte às propriedades ACID (Atomicidade, Consistência, Isolamento e Durabilidade).

Tudo isso funcionou lindamente, até que:

• o hardware ficou mais barato,
• o volume dos dados cresceu,
• vários formatos de dados surgiram,
• os sistemas precisando de dados em uma velocidade enorme,
• diferentes dispositivos acessando os dados,
• muitos usuários simultâneos acessando os dados….

A primeira alternativa no novo cenário é a melhoria dos servidores… Ou seja, adicionar mais memória, mais CPUs… Enfim melhorar o hardware. Chamamos esta melhora de escalar verticalmente, em outras palavras, melhorar o desempenho de um sistema melhorando o hardware do servidor.

Mas o servidor é finito… E quando não dá mais para melhorar o hardaware? E quando o desempenho passa a ser o requisito principal? E quando as propriedades ACID não são necessárias? Neste cenário surgem os lindos bancos de dados NoSQL!

SQL ou NOSQL? Neste caso SQL (ou relacional ? )

Não tem uma receita mágica, mas vou dar algumas dicas aqui.

Minha primeira consideração, é sobre as propriedades ACID… Alguns bancos de dados NoSQL tem suporte a elas, mas isso não significa que o desempenho deles seja ideal. Esteja atento, porque se você precisa muito destas propriedades, talvez seja melhor usar um banco de dados relacional.

Quanto ao formato dos dados, se você conhece todos as colunas das suas tabelas? As suas tabelas são estáveis?

Se você respondeu sim para estas perguntas, mais um ponto para os bancos de dados relacionais.

Ainda falando em colunas, se você conhece os tipos de dados, e eles são muito importantes para as suas aplicações, os bancos de dados relacionais são bons aliados, porque ao criar uma coluna, é obrigatório informar qual é o tipo dela.

Se o seu volume de dados é médio (na ordem de alguns terabytes) e não vai crescer muito além disso, o banco de dados relacional deve ser considerado.

Quando falamos de um banco de dados NoSQL, devemos lembrar que eles não possuem schema, o que facilita muito no deployment e evolução, mas dificulta muito na governança.  Sendo assim avalie se o seu time não segue processos, não tem padrões, tem alta rotatividade, é melhor usar um banco de dados relacional (nada ciêntifico aqui meus amigos, opinião da Dani, porque eu realmente acho que para usar um BD NoSQL é preciso maturidade para lidar com a liberdade que eles oferecem).

Imagine que você tem o seguinte modelo de dados

E você deseja excluir os dados da Entidade 1. Você não conseguirá excluir os dados da tabela Entity, onde o ID é igual a 1 se existirem dados nas tabelas Organization e Person onde o entityID é igual a 1. Essa exclusão só ocorrerá com sucesso, se os dados das tabelas Person e Organization onde o entityID é igual a 1, forem excluídos primeiro e depois os dados da tabela Entity.

Isso acontece por conta da integridade referencial. Por padrão, os bancos de dados relacionais têm mecanismos para garantir a integridade referencial de forma automática. Nenhum banco de dados NoSQL tem esta característica.

Atualmente os bancos de dados NoSQL possuem ferramentas medianas para administração, mas eu sinceramente, acho os bancos de dados relacionais mais completos neste sentido.

Cuidado com as licenças! Vejo muita gente fazendo a divisão NoSQL são gratuitos e os relacionais pagos, e a história não é bem assim. Ao escolher qualquer banco de dados esteja atento ao tipo de licença, de forma geral entre os bancos de dados Relacionais o PostgreSQL é o que possui a licença mais permissiva, e tem uma comunidade linda (aliás vem aí o PGCONF 2020)! MySQL tem uma versão Community e uma versão Enterprise, ou seja, não é gratuito em todas as situações, SQL Server tem diversas edições diferentes de acordo com as funcionalidades e o hardware do servidor, assim como o Oracle.

Agora quando o assunto é hardaware, fique atento! Bancos de dados relacionais utilizam hardware mais robusto (modo fofo de falar mais caro).

Outro ponto importante quando falamos de hardware e bancos de dados relacionais, é que ao escalar verticalmente precisamos verificar quais os custos que estão envolvidos, porque o licenciamento do SQL Server (até a versão 2017) e do Oracle é por core, em outras palavras, antes de colocar mais CPUs no seu servidor, verifique se não ocasionará custos com a licença.

Existem situações onde os dados estão naturalmente em formato tabular, neste caso, talvez seja mais conveniente mantê-los neste formato, e usar um banco de dados relacional.

Outra coisa interessante quando falamos em formato tabular, é que todas as linhas têm o mesmo conjunto de colunas, o que é natural para os bancos de dados relacionais.

Juro que estamos terminando, mas aspecto relevante é a redundância. Se ela é um problema para os nossos sistemas, ou os dados existem e estão normalizados, o banco de dados relacional é uma boa sacada.

E para terminar (esta parte)… Quando criamos um banco de dados relacional a modelagem é a primeira etapa, e normalmente atende a diversas consultas e usos diferentes. Nos bancos NoSQL não é bem assim.

Dica final

Amigos, vejo muitos projetos falharem usando bancos de dados NoSQL… Vejo muitos projetos falharem usando bancos de dados Relacionais… Logo o problema não é o tipo de Banco de Dados!

Seu projeto tem menos chances de falhar se você lembrar destes itens fofinhos:

• Modelo de dados é importante para te ajudar a entender o que você está fazendo;
• Governança de dados é indispensável para impedir que você tenha que lidar com o caos;
• Agilidade e BD combina sim! E combina com governança também! No BD está o ativo mais valioso da organização e sendo assim precisamos de cuidado, o que não impede as entregas de serem ágeis.
• Padronize tudo o que for possível para você e seu time não enlouquecerem, por exemplo:
  • Nome de BD;
  • Nome de tabela,
  • Nome de Coluna;
  • Nome de índice;
  • Nome de chave estrangeira;
  • Nome de check constraint;
  • Nome de defaults
• Habilite somente os recursos que você realmente precisa;
• Antes de afirmar que vai usar vários bancos de dados diferentes, verifique os recursos disponíveis no banco de dados que você usa.

Para finalizar o post e sem fechar o assunto…

No GitHub tem uma planilha bem linda com alguns itens que você deve avaliar para decidir usar um banco de dados relacional. Conforme esta série for crescendo, a planilha vai ficando mais completa.

Mas só isso não tem graça!  Planilha é nossa, então fique a vontade para mandar suas colaborações.

Acesse a planilha neste link. 

Créditos, Referências e afins…

Peguei a figura inicial de um post muito bom, sobre SQL ou NOSQL, da minha linda Lauren Ferreira, e super recomendo a leitura: https://medium.com/devtranslate/diferencas-entre-sql-e-nosql-51311f9069bd

Post antigo, mas fofinho, sobre transações: Porque você precisa conhecer transações?

Autora

Danielle Monteiro

Outros posts desta série

Se você quer ler os outros posts desta série, acesse os links abaixo:

• SQL ou NoSQL – Parte 2 – Quando usar o MongoDB? http://db4beginners.com/blog/sql-ou-nosql- mongodb
• SQL ou NoSQL – Parte 3 – Quando usar o Neo4J? http://db4beginners.com/blog/sql-ou-nosql-Neo4J