Acabei de começar a usar um banco de dados baseado em documentos NoSQL (MongoDB) e estou curioso sobre as práticas recomendadas para projetar bancos de dados.
Presumo que a arquitetura deva ser diferente dos bancos de dados relacionais? Ainda devo procurar um banco de dados normalizado?
Por exemplo, eu tenho um caso de uso específico;
Eu tenho um usuário com um histórico de aluguel (matriz de endereços). Essa matriz deve ser uma matriz no usuário ou como uma coleção separada com uma chave compartilhada?
Respostas:
A abordagem apropriada para o design de banco de dados NoSQL é um DDD ( Domain Driven Design ). Para algumas pessoas que costumavam projetar RDBMS, o NoSql se parece com os antipadrões Sql e faz mais sentido quando considerado no escopo de um DDD.
Dependendo do uso dos endereços, você pode defini-lo como um objeto de valor dentro do modelo / entidade do histórico de aluguel.
Aqui estão algumas referências que podem esclarecer os pensamentos sobre o design com o NoSQL:
fonte
TL; DR
A normalização no RDBMS permite aproveitar os pontos fortes do paradigma relacional.
A desnormalização no NoSQL permite que você aproveite os pontos fortes do paradigma NoSQL.
Resposta longa
Os RDBMS são ótimos porque permitem modelar entidades estruturadas únicas (mutáveis ou não) e seus relacionamentos entre si. Isso significa que é muito fácil trabalhar no nível da entidade, atualizando suas propriedades, inserindo outro, excluindo um, etc. Mas também é ótimo para agregá-los dinamicamente, um cachorro com seu dono, um cachorro com as casas em que residem etc. O RDBMS fornece ferramentas para facilitar tudo isso. Ele se juntará a você, lidará com mudanças atômicas entre entidades para você, etc.
Os bancos de dados NoSQL são ótimos porque permitem modelar agregados semi-desestruturados e entidades dinâmicas. Isso significa que é muito fácil modelar entidades em constante mudança, entidades que nem todos compartilham os mesmos atributos e agregados hierárquicos.
Para modelar para o NoSql, você precisa pensar em termos de hierarquia e agregados, em vez de entidades e relações. Portanto, você não tem pessoa, endereço de aluguel e uma relação entre eles. Você tem registros de aluguel que agregam para cada pessoa quais endereços de aluguel eles tiveram.
Você precisa perguntar quais dados precisarei alterar juntos. Quais dados estão agrupando logicamente os outros dados. No seu caso, uma pessoa parece ser um bom agregado. Qual é o ponto de entrada lógico para o restante dos dados.
NoSQL, digamos, armazene uma coisa que tem outras que têm coisas próprias. Devolva-me toda a hierarquia das coisas. Deixe-me alterá-lo como eu quiser, agora substitua toda a hierarquia de coisas pela minha alterada. Isso é praticamente tudo o que você oferece. Por que é útil? Se o que você tem é uma hierarquia de coisas com as quais você sempre interage como um todo. Ou se você precisar escalar massivamente.
Tudo o que o RDBMS fornece, você precisará implementar manualmente no código e no seu esquema. Você precisará ingressar no código se precisar de um agregado de agregados. Você precisará analisar se precisar apenas de parte de um agregado. Você precisará verificar a exclusividade se não quiser duplicar as coisas. Você precisará implementar sua própria lógica transacional ao trabalhar com agregados, etc.
Portanto, ter uma mesa grande com tudo o que você precisa é o caminho a seguir no NoSql. Como a atomicidade é garantida apenas nesse nível, e também o desempenho. Descobrir suas relações cedo é importante. É isso que é a desnormalização.
No RDBMS, a desnormalização efetivamente prejudica seu banco de dados para um NoSQL. Então normalmente você quer o contrário, isto é, normalização. Caso contrário, você deve usar um banco de dados NoSQL. A menos que você precise de um pouco dos dois.
fonte