SQL ou NoSQL? Talvez a pergunta certa não seja essa

Leia. Curta. Comente. Compartilhe.

...

Entenda de forma simples por que SQL e NoSQL resolvem problemas diferentes e como JPA, @Entity, MongoDB e @Document aparecem nessa história.

...

Quando você começa a estudar banco de dados, uma dúvida aparece rapidinho:

SQL ou NoSQL? Qual é melhor?

Só que essa pergunta é parecida com perguntar:

“O que é melhor: uma mala ou um guarda-roupa?”

Depende.

Para guardar suas roupas em casa, provavelmente o guarda-roupa.

Para viajar, boa sorte tentando despachar um guarda-roupa no aeroporto.

Com banco de dados acontece algo parecido.

Primeiro, o que muda entre SQL e NoSQL?

Imagine uma loja organizando seus clientes.

Em um banco SQL, você pode ter informações organizadas em tabelas:

CLIENTES

id | nome  | email
1  | Ana   | ana@email.com
2  | Pedro | pedro@email.com

Existe uma estrutura bem definida, com linhas, colunas e relacionamentos.

É como uma planilha muito bem organizada.

Já em um banco NoSQL, como o MongoDB, os dados podem ser armazenados em documentos:

{
"nome": "Ana",
"email": "ana@email.com",
"telefone": "99999-9999"
}

Outro cliente poderia até ter informações diferentes.

A estrutura pode ser mais flexível.

Então NoSQL é mais moderno e melhor?

Não.

E SQL também não é automaticamente melhor.

Eles resolvem necessidades diferentes.

Imagine um sistema financeiro.

Você provavelmente terá clientes, contas, transações e vários relacionamentos importantes entre essas informações.

Um banco relacional pode fazer bastante sentido.

Agora imagine uma aplicação que recebe dados com estruturas que mudam bastante ou documentos que não precisam seguir exatamente o mesmo formato.

Um banco NoSQL pode ser interessante.

Por isso, antes de perguntar:

“Qual banco é melhor?”

Talvez seja mais útil perguntar:

“Como meus dados precisam ser armazenados e consultados?”

E onde entra o JPA?

No Java com Spring, é muito comum encontrar JPA trabalhando com bancos relacionais.

Você cria uma classe:

@Entity
public class Cliente {

  private Long id;
  private String nome;
  private String email;
}

O @Entity basicamente avisa:

“Spring, essa classe representa algo que será persistido no banco relacional.”

É como colocar uma etiqueta na caixa dizendo o que existe lá dentro.

E no MongoDB?

Com MongoDB, podemos encontrar algo parecido:

@Document
public class Cliente {

  private String id;
  private String nome;
  private String email;
}

Aqui aparece o @Document.

A ideia continua sendo representar dados da aplicação, mas agora estamos trabalhando com documentos, e não com as tradicionais tabelas de um banco relacional.

Uma anotação pequena, mas que já entrega uma pista enorme sobre como aquela aplicação está armazenando seus dados.

3 coisas para lembrar antes de escolher

1. Pense nos dados antes da tecnologia

Não escolha MongoDB só porque parece moderno.

E não escolha SQL apenas porque você já conhece.

Primeiro entenda o problema.

2. Relacionamentos importam

Se seus dados possuem muitos relacionamentos e precisam de bastante consistência, isso influencia bastante a escolha.

É como organizar uma família.

Você não quer descobrir depois que cadastrou a avó como filha do cachorro.

3. Flexibilidade também tem preço

Ter uma estrutura mais flexível pode ser ótimo.

Mas flexibilidade sem organização pode virar:

“Cada documento de um jeito e que Deus ajude quem precisar entender isso daqui a seis meses.”

NoSQL não significa ausência de organização.

No fim, não existe um vencedor

SQL e NoSQL não precisam entrar em uma arena para descobrir quem sobrevive.

Existem aplicações que usam SQL.

Outras usam NoSQL.

E existem sistemas que usam os dois, cada um resolvendo uma necessidade diferente.

Por isso, quando alguém perguntar:

“SQL ou NoSQL?”

Antes de escolher um lado, vale perguntar:

“Qual problema estamos tentando resolver?”

Essa pergunta provavelmente vai levar a uma decisão muito melhor.

>> E você, quando começou a estudar banco de dados também achava que precisava escolher um lado: SQL ou NoSQL?

___

Indicação de livro

Designing Data-Intensive Applications

Autor: Martin Kleppmann

É uma leitura mais avançada, mas excelente para entender que escolher tecnologias de dados vai muito além de decidir entre SQL e NoSQL. É daqueles livros para guardar na lista e revisitar conforme você evolui.