Olá a todos.
Eu estou avançando na formatação das ideias para meu TCC e, após decidir utilizar arquitetura baseada em microserviços, também optarei por utilizar NoSQL com MongoDB.
Ocorre que eu nunca projetei nada para este banco de dados e estou meio perdido em como realizar a modelagem dos documentos que serão armazenados pelo mesmo.
Vamos contextualizar, eu sou desenvolvedor java há 7 anos, trabalhei sempre com bases de dados relacionais, seja com queries nativas ou utilizando ORM (Hibernate e eclipselink, especificamente).
Devido a isso, devo admitir que tenho vícios de programador, como o de sempre pensar olhando para um conjunto de tabelas, relacionadas por suas PKs e FKs, constraints e afins.
Ocorre que, até onde sei e consegui pesquisar, o mundo OO dispensa tais elementos, é possível ter documentos gigantescos, compostos por N objetos que representam toda uma estrutura de dados.
Um exemplo bem claro:
Uma empresa de telefonia possui produtos nas categorias telefonia fixa, telefonia movel, planos de internet e planos de tv paga. Cada cliente pode comprar produtos de cada uma das categorias isoladamente ou agrupadas em qualquer conjunto, inclusive combos contendo todas as categorias. Cada cliente pode possuir diversos contratos distintos, cada qual com seu(s) produto(s) específicos.
Neste caso, eu teria várias tabelas (e suas PKs e FKs) para armazenar cada produto, categoria, cliente, cliente_produto, etc.
Agora, eu não consigo pensar em como seria o melhor modelo para transformar isso em documentos do MongoDB, de maneira que eu evite a duplicidade de dados. Seria ideal replicar o modelo relacional, ter um documento para cada classe ou o mais sensato é colocar um objeto gigantesco que representa o cliente e ir preenchendo-o com vários outros objetos que representem os contratos que o mesmo eventualmente possua.
Eu imagino que a resposta seja “depende”, mas, eu preciso de outras visões, para não ter problemas ao prosseguir com a escolha que fiz.
Caso possam me esclarecer esta dúvida com a sugestão de bibliografias que auxiliem neste entendimento, ficarei muito grato.
Se o data model já não é baseado em documento, você vai precisar de um ODM (object-documento mapping). Nesse sentido não é diferente de um banco de dados SQL que precisa de mapeamento quando usado com OO.
Isso funciona num cenário totalmente consistente, o banco nosql abre mão de consistência em troca de escalabilidade.
Tem certeza que teu cenário é para banco de dados baseados em documentos ao invés de relacional mais voltado para o transacional? Cuidado para não usar só por moda. Até modelagem OO nem sempre é necessária, principalmente em backend.
@javaflex, como o projeto é para um TCC, realmente um MySQL resolveria e atenderia 100%. Ocorre que eu pretendo desenvolver este projeto baseado em microserviços e aplicar big data e algumas coisas mais, por isso eu acredito que o MongoDB possa me auxiliar melhor neste quesito.
Eu sei que o big data não depende de um banco NoSQL, mas eu quero, juntamente com o aprendizado, concretizar estes conhecimentos.
@pfk66, pelo que entendi, é válido ter
{
'_id': 'xyz',
'nome' : 'Astolpho',
'produtos' : [
{
'_id': '123a',
'descricao': 'Plano fixo100 minutos'
},
{
'_id': '123x',
'descricao': 'Plano movel100 minutos'
},
{
'_id': '123y',
'descricao': 'Plano TV familia +'
},
]
}
Certo?
A questão é, considerando este modelo, como eu trabalharia o cadastro de produtos?
Entendo. Trabalho academico acontece isso mesmo.
Não sei se entendi sua pergunta mas você trabalha usando a API do mongodb pra cadastrar os documentos. O banco não precisa saber nada sobre sua hierarquia de objetos e relacionamentos, apenas sobre documentos que são schema-free.
Por isso duplicidade é fundamental. Não é comum ter referencias entre documentos.
Este é um documento sobre os produtos adquiridos pelo cliente numa data, certo? Cadastro de produtos disponíveis para venda seria outro documento. Como @pfk66 falou, é “schema-free”.
@javaflex, entendi.
Até por quê, os dados do produto para venda serão diferentes, terão mais atributos, correto?
Depende das características da sua aplicação, mas em geral sim.
Foi o que eu imaginei. Mas muito obrigado por esclarecerem esta dúvida. Como eu estou saindo da zona de conforto, o menor dos detalhes traz insegurança.
Aqui tenho uns posts sobre a minha monografia sobre NoSQL . Talvez ajude em algo em seu trabalho.
https://danieldiasjava.wordpress.com/category/academico/
{ },.
Por serem documentos diferentes. O plano que o cliente adquiriu numa época não obrigatoriamente deve existir no documento de produtos a venda hoje.
De Nada.