Close Menu
Código Simples .NETCódigo Simples .NET
    Facebook X (Twitter) Instagram
    Trending
    • NewSQL em 2025: O Estado Atual, Tendências e o Futuro dos Bancos de Dados Relacionais Escaláveis
    • 12 Regras Essenciais para Reduzir a Latência de Aplicações
    • Cache Hit Ratio: Como uma Simples Métrica Pode Revolucionar sua Arquitetura
    • Como a Uber calcula o tempo estimado de chegada
    • 30 APIs Gratuitas para desenvolvedores
    • Por que escalar escrita é tão mais difícil do que escalar leitura?
    • MongoDB Analyzer para .NET: Visualize e otimize suas consultas de forma simples
    • Cardinalidade: O Conceito que Transforma o Desempenho de Bancos de Dados SQL e NoSQL
    Facebook X (Twitter) Instagram
    Código Simples .NETCódigo Simples .NET
    Código Simples .NETCódigo Simples .NET
    Home»Dicas»Onde aplicar e quando aplicar modelagem orientada à documentos – NoSQL

    Onde aplicar e quando aplicar modelagem orientada à documentos – NoSQL

    Leandro DominguesBy Leandro Domingues16 de abril de 20173 Mins Read Dicas
    Share
    Facebook Twitter LinkedIn WhatsApp Copy Link

    Fala galera, blz? Hoje vou falar um pouco sobre Document Model ou Modelo Orientado a Documento.

    Esse tipo de modelo de dados é um dos pilares do NoSQL, o banco que utilizo no meu dia-a-dia é o MongoDB. Um banco de dados NoSQL open-source com uma comunidade gigantesca espalhada pelo mundo, confira mais aqui.

    Quando o Document Model é uma boa?

    Bem, é uma pergunta relativa… o document model pode ser encaixado em vários cenários, porém, sempre ressalto que não serve pra tudo. Quando estamos modelando uma aplicação devemos pensar sempre em como vamos querer exibir nossos dados. Claro que no meio desse planejamento podemos preferir dar mais performance para escrita ou em outros casos para leitura, mas uma hora teremos que decidir o que será mais importante para nosso produto final.

    Tenho utilizado o document model para várias aplicações nos últimos anos, desde as mais simples até aplicações complexas que exigem um grande número de escrita ou leitura dos dados, e tenho observado que esse tipo de modelo se aplica muito bem em diferentes situações.

    Por experiência própria de anos desenvolvendo em cima de bancos relacionais como o MS SQL Server, vi que um dos maiores ofensores de performance nas aplicações são os nossos queridos JOINs. No modelo relacional utilizamos os JOINs para relacionar uma ou várias tabelas do nosso modelo, isso pode causar perda de performance em alguns casos. No modelo de documentos temos o que chamamos de agregado, ou seja, trazemos para um único documento os dados que teríamos espalhados em várias tabelas. Vejamos um exemplo:

    Na figura acima temos a representação de um modelo relacional com três tabelas, nesse caso faremos o relacionamento através o ClienteId. No document model esse mesmo modelo ficaria representado assim:

    {
    	"clienteId": 1,
    	"nome": "Leandro",
    	"sobrenome": "Domingues",
    	"dataNascimento": ISODate("1982-08-24T00:00:00.000Z"),
    	"enderecos":[
    		{
    			"endereco": "Rua X",
    			"bairro": "Jardim Y",
    			"cidade": "Sao Paulo",
    			"uf": "SP",
    			"cep": "00000-000"
    		},
    		{
    			"endereco": "Rua Y",
    			"bairro": "Jardim X",
    			"cidade": "Sao Paulo",
    			"uf": "SP",
    			"cep": "00000-000"
    		}
    	],
    	"telefones": [
    		{
    			"ddd": 11,
    			"telefone": "99999-9999"
    		},
    		{
    			"ddd": 11,
    			"telefone": "88888-8888"
    		}
    	]
    },
    {
    	"clienteId": 2,
    	"nome": "João",
    	"sobrenome": "Silva",
    	"dataNascimento": ISODate("1979-01-02T00:00:00.000Z"),
    	"enderecos":[
    		{
    			"endereco": "Rua T",
    			"bairro": "Jardim E",
    			"cidade": "Guarulhos",
    			"uf": "SP",
    			"cep": "00000-000"
    		}
    	],
    	"telefones": [
    		{
    			"ddd": 11,
    			"telefone": "93829-9980"
    		},
    		{
    			"ddd": 11,
    			"telefone": "94338-9873"
    		}
    	]
    },
    {
    	"clienteId": 3,
    	"nome": "Maria",
    	"sobrenome": "Santos",
    	"dataNascimento": ISODate("1965-04-03T00:00:00.000Z"),
    	"enderecos":[
    		{
    			"endereco": "Rua R",
    			"bairro": "Jardim F",
    			"cidade": "Brasília",
    			"uf": "DF",
    			"cep": "00000-000"
    		}
    	],
    	"telefones": [
    		{
    			"ddd": 61,
    			"telefone": "2333-9099"
    		}
    	]
    }

     

    Uma das possibilidades existentes no document model, é a de agregar conteúdo ao nosso documento principal, nesse caso podemos ter arrays contendo outros documentos, como no caso dos endereços e telefones.

    E o desenvolvimento como fica?

    Na minha opinião esse modelo de dados veio para ajudar e muito os desenvolvedores, claro que para queries mais complexas é altamente aconselhável a análise de um DBA, porém, para queries mais simples o desenvolvedor se sentirá muito mais familiarizado com o JSON.

    Agregando o conteúdo a um único documento, podemos ter chaves de pesquisa mais simples, retornando em nossas consultas todo o conteúdo do documento.

    Obviamente, dependendo da quantidade de dados armazenada em um documento, teremos que utilizar de alguns recursos disponíveis no MongoDB para otimizar o retorno de nossa query. Por exemplo se quisermos retornar somente os endereços do cliente 1 poderíamos utilizar a seguinte query:

    db.clientes.find({clienteId: 1}, {enderecos: 1})

     

    Nessa query, dizemos ao MongoDB para nos retornar o cliente 1, porém, como segundo parâmetro da função especificamos qual campo de nossa coleção queremos no retorno, nesse caso, escolhemos o endereço. Nesse parâmetro podemos colocar vários campos para serem retornados:

    db.clientes.find({clienteId: 1}, {nome:1, enderecos:1})

     

    Nota: no MongoDB os documentos são armazenados no formato BSON. Cada documento tem o tamanho máximo de 16MB, esse limite ajuda a assegurar que um único documento não utilizará muita memória RAM ou exagere no tráfego de rede. Para conhecer mais sobre os limites de um documento veja aqui.

    Conclusão

    Bem, como disse no início o modelo orientado a documentos é muito legal, porém, não resolve todos os problemas. Devemos pensar muito bem antes de começar a modelar nossa aplicação.

    Vale a pena olhar esse modelo de dados!

    Espero que tenham gostado e até mais!

     

    Referência: MongoDB Docs

    Share. Facebook Twitter LinkedIn Telegram WhatsApp Copy Link
    Leandro Domingues
    • Website
    • X (Twitter)
    • LinkedIn

    Formado em Engenharia da Computação, entusiasta de tecnologias open-source, bigdata e NoSQL. MongoDB Ambassador / Evangelist, Top 50 Certificado em Neo4j, utiliza MongoDB e SQL Server criando aplicações em NodeJS há 3 anos. CTO / Co-owner da Cluster Consultoria, uma empresa especializada em bancos de dados NoSQL

    Posts Relacionados

    MongoDB Analyzer para .NET: Visualize e otimize suas consultas de forma simples

    NoSql 7 de fevereiro de 20255 Mins Read

    Cardinalidade: O Conceito que Transforma o Desempenho de Bancos de Dados SQL e NoSQL

    NoSql Sql 14 de janeiro de 20257 Mins Read

    Entendendo os diferentes tipos de locks em bancos de dados e como evitá-los

    NoSql Sql 2 de julho de 20248 Mins Read
    Newsletter

    Digite seu endereço de e-mail para receber notificações de novas publicações por e-mail.

    Junte-se a 25mil outros assinantes
    Posts recentes
    • NewSQL em 2025: O Estado Atual, Tendências e o Futuro dos Bancos de Dados Relacionais Escaláveis
    • 12 Regras Essenciais para Reduzir a Latência de Aplicações
    • Cache Hit Ratio: Como uma Simples Métrica Pode Revolucionar sua Arquitetura
    • Como a Uber calcula o tempo estimado de chegada
    • 30 APIs Gratuitas para desenvolvedores
    Categorias
    • Arquitetura (14)
      • Testes (2)
    • Asp.net (120)
      • C# (89)
      • Mvc (13)
    • Banco de dados (90)
      • NoSql (58)
      • Sql (38)
    • Boas práticas (29)
      • Gestão & Produtividade (1)
      • Metodologias Ágeis (6)
    • Cursos (52)
    • Dicas (105)
    • Front-End (92)
    • IA (1)
    • Linux (6)
    • NodeJS (4)
    • Post do Leitor (9)
    • Python (5)
    • Seo (12)
    • Tecnologia (30)
      • ITIL (1)
      • Padrões de Projeto (4)
    • Testes (2)

    VEJA TAMBÉM

    Cursos
    12 de fevereiro de 20166 Mins Read

    1000 livros gratuitos sobre programação!

    Olha que dica bacana! A pagina só com livros sobre programação é mantida no GitHub…

    30 APIs Gratuitas para desenvolvedores

    Facebook X (Twitter) Instagram LinkedIn

    Type above and press Enter to search. Press Esc to cancel.

    Vá para versão mobile