Modelagem de Dados MongoDB

Os dados no MongoDB possuem um esquema flexível schema.documents na mesma coleção. Os documentos na mesma coleção. Eles não precisam ter o mesmo conjunto de campos ou campos comuns na estrutura da coleção, os documentos podem conter diferentes tipos de dados.

Design do modelo de dados

O MongoDB oferece dois tipos de modelos de dados: modelo de dados embutido e modelo de dados normalizado. De acordo com as necessidades, você pode usar qualquer um desses dois modelos ao preparar documentos.

Modelo de dados embutido

Neste modelo, você pode colocar todos os dados relacionados (embutidos) em um único documento, o que também é conhecido como modelo de dados não normalizado.

Por exemplo, supondo que estejamos obtendo detalhes do funcionário em três documentos diferentes (Detalhes_Pessoais, Contato e Endereço), podemos embutir todos os três documentos em um documento, conforme mostrado a seguir:

{
	_id:,
	ID_Empregado: "10025AE336"
	Detalhes_Pessoais: {
		Nome: "Radhika",
		Sobrenome: "Sharma",
		Data_de_Nascimento: "1995-09-26"
	}
	Contato: {
		e-mail: "[email protected]"
		telefone: "9848022338"
	}
	Endereço: {
		cidade: "Hyderabad",
		Área: "Madapur",
		State: "Telangana"
	}
}

Modelo de dados normalizado

Neste modelo, você pode usar referências para se referir a subdocumentos no documento original. Por exemplo, você pode reescrever o seguinte documento como modelo normalizado:

Empregado:

{
	_id: ObjectId101>
	ID_Empregado: "10025AE336"
}

Detalhes_Pessoais:

{
	_id: ObjectId102>
	empDocID: "ObjectId"101"
	Nome: "Radhika",
	Sobrenome: "Sharma",
	Data_de_Nascimento: "1995-09-26"
}

Contato:

{
	_id: ObjectId103>
	empDocID: "ObjectId"101"
	e-mail: "[email protected]"
	telefone: "9848022338"
}

Endereço:

{
	_id: ObjectId104>
	empDocID: "ObjectId"101"
	cidade: "Hyderabad",
	Área: "Madapur",
	State: "Telangana"
}

Considerações ao projetar arquitetura no MongoDB

• Designar a arquitetura conforme solicitado pelo usuário.

• Se combinados, combiná-los em um documento. Caso contrário, separem (mas certifique-se de que não seja necessário conectar).

• Copiar dados (mas com restrições), pois o espaço em disco é mais barato do que o tempo de computação.

• Realizar joins na escrita, em vez de na leitura.

• Otimizar sua solução para os casos de uso mais comuns.

• Realizar agregações complexas na arquitetura.

Exemplo online

Supondo que o cliente precise de um blog/O site realiza o design do banco de dados e verifica as diferenças entre o design de schema do RDBMS e o MongoDB. O site tem os seguintes requisitos.

• Cada postagem tem um título único, descrição e URL.

• Cada postagem pode ter uma ou mais etiquetas.

• Cada postagem tem o nome do autor e o número total de curtidas.

• Cada postagem possui comentários fornecidos pelos usuários, bem como seus nomes, mensagens, data e hora do post e curtidas.

• Em cada postagem, pode haver zero ou mais comentários.

Na arquitetura RDBMS, o design para o requisito acima terá pelo menos três tabelas.

No modelo MongoDB, o design terá uma coleção de postagens e a seguinte estrutura-

{
　　　_id:　POST_ID
　　　title:　TITLE_OF_POST,　
　　　description:　POST_DESCRIPTION,
　　　by:　POST_BY,
　　　url:　URL_OF_POST,
　　　tags:　[TAG1,　TAG2,　TAG3],
　　　likes:　TOTAL_LIKES,　
　　　comments:　[	
　　　　　　{
　　　　　　　　　user:'COMMENT_BY',
　　　　　　　　　message:　TEXT,
　　　　　　　　　dateCreated:　DATE_TIME,
　　　　　　　　　like:　LIKES　
　　　　　　}
　　　　　　{
　　　　　　　　　user:'COMMENT_BY',
　　　　　　　　　message:　TEXT,
　　　　　　　　　dateCreated:　DATE_TIME,
　　　　　　　　　like:　LIKES
　　　　　　}
　　　}
}

Portanto, ao exibir dados, no RDBMS, você precisa conectar três tabelas, enquanto no MongoDB, os dados serão exibidos a partir de uma única coleção.