Explore o novo chatbot do Developer Center! O MongoDB AI chatbot pode ser acessado na parte superior da sua navegação para responder a todas as suas perguntas sobre o MongoDB .

Junte-se a nós no Amazon Web Services re:Invent 2024! Saiba como usar o MongoDB para casos de uso de AI .
Desenvolvedor do MongoDB
Central de desenvolvedor do MongoDBchevron-right
Produtoschevron-right
MongoDBchevron-right

Mapeando Termos e Conceitos do SQL para o MongoDB

Lauren Schaefer15 min read • Published Jan 07, 2022 • Updated Oct 01, 2024
SQLMongoDB
Ícone do FacebookÍcone do Twitterícone do linkedin
Avalie esse Artigo
star-empty
star-empty
star-empty
star-empty
star-empty
Talvez, como eu, você tenha sido criado em bancos de dados SQL. Você pode normalizar habilmente um banco de dados e, depois de anos trabalhando com tabelas, você também pensa em linhas e colunas.
Mas agora que você decidiu mergulhar de cabeça no maravilhoso mundo dos bancos de dados NoSQL, está começando a explorar o MongoDB. Talvez você esteja se perguntado o que precisa fazer de diferente. Você pode simplesmente traduzir suas linhas e colunas em campos e valores? Você realmente precisa mudar a maneira como pensa em armazenar seus dados?
Responderemos a essas e outras perguntas nesta série de artigos em três partes. Abaixo está um resumo do que abordaremos hoje:
Este artigo é baseado em uma apresentação que fiz na MongoDB World e no MongoDB.local Houston chamada "Do SQL ao NoSQL: mudando sua mentalidade."
Se você preferir vídeos a artigos, confira a gravação. Os slides estão disponíveis aqui.

Conheça Ron

Sou um grande fã do melhor programa de TV já criado: Confusões de Leslie. Sim, escrevi a frase anterior como se fosse um fato, porque na verdade é.
Não. Essa é sua opinião. Essa é a definição de uma opinião.
Este é o Ron. Ron gosta de mulheres fortes, bacon e de ficar fora da rede.
Quando se trata de bacon, esteja preparado
Na 6ª temporada, Ron descobre Yelp. Ron acha o Yelp ótimo, porque ele curte a ideia de avaliar os lugares por onde passou.
Entretanto, o Yelp é muito "digital" para Ron. Ele pega sua amada máquina de escrever e começa a digitar resenhas que pretende enviar por correio tradicional.
Ron escreve algumas críticas incríveis. Abaixo está uma das minhas favoritas.
Caro iogurte congelado,
Você é a sobremesa mais sem graça que existe.
Seja sorvete ou não seja nada.
Zero estrelas.
Infelizmente, vejo três grandes problemas com o plano dele:
  1. O correio tradicional é muito mais lento do que publicar a avaliação no Yelp, onde ela estará instantaneamente disponível para qualquer pessoa ler.
  2. A empresa que ele está analisando pode nunca abrir a carta que ele envia, pois pode presumir que se trata de uma correspondência indesejada.
  3. Ninguém mais se beneficiará da sua avaliação. (É exatamente esse tipo de avaliação que eu gostaria de encontrar na Amazon!)

Por que estou falando do Ron?

Então por que estou falando sobre Ron no meio deste artigo sobre como mudar do SQL para o MongoDB?
Ron percebeu o valor do Yelp e se inspirou na nova tecnologia. No entanto, ele trouxe consigo seus hábitos tradicionais e não percebeu o valor total da tecnologia.
Isso é semelhante ao que normalmente vemos quando as pessoas migram de um banco de dados SQL para um banco de dados NoSQL, como o MongoDB. Eles adoram a ideia do MongoDB e são inspirados pelo poder do modelo flexível de dados de documentos. No entanto, frequentemente trazem consigo suas mentalidades de SQL e não percebem o valor total do MongoDB. Na verdade, quando as pessoas não mudam a maneira como pensam sobre a modelagem de seus dados, elas têm dificuldades e, às vezes, falham.
Ron joga computador no lixo
Não seja como o Ron. (Pelo menos nesse caso, porque, na maioria dos casos, Ron é incrível.) Não fique preso ao SQL. Mude sua mentalidade e aproveite todo o valor do MongoDB.
Antes de abordarmos como mudar sua forma de pensar, vamos começar respondendo a algumas perguntas frequentes sobre bancos de dados não relacionais e analisando as noções básicas de como armazenar dados no MongoDB.

Banco de dados relacional e bancos de dados não relacionais

Quando converso com desenvolvedores, eles geralmente me fazem perguntas como: "Quais casos de uso são bons para o MongoDB?" Os desenvolvedores geralmente têm a sensação de que os bancos de dados não relacionais (ou bancos de dados NoSQL) como o MongoDB são para casos de uso específicos e de nicho.
O MongoDB é um banco de dados de uso geral que pode ser usado em uma variedade de casos de uso em quase todos os setores. Para obter mais detalhes, consulte Casos de uso do MongoDB, Indústrias do MongoDB e o Whitepaper de orientação de caso de uso do MongoDB, que inclui um resumo de quando você deve avaliar outras opções de banco de dados.
Outra pergunta comum é: "Se meus dados são relacionais, por que eu usaria um banco de dados não relacional?"
O MongoDB é considerado um banco de dados não relacional. No entanto, isso não significa que o MongoDB não armazena bem os dados de relacionamento. (Sei que usei apenas uma dupla negativa. Continue comigo.) O MongoDB armazena dados de relacionamento de uma maneira diferente. Na verdade, muitos consideram a forma como o MongoDB armazena dados de relacionamento mais intuitiva e mais reflexiva dos relacionamentos do mundo real que estão sendo modelados.
Vamos dar uma olhada em como o MongoDB armazena dados.

O Modelo de Documento

Em vez de tabelas, o MongoDB armazena dados em documentos. Não, Clippy, não estou falando de documentos do Microsoft Word.
Clippy levanta as sobrancelhas
Estou falando de documentos BSON. BSON é uma representação binária de documentos JSON (JavaScript Object Notation). Os documentos provavelmente lhe parecerão tranquilos se você usou alguma linguagem de programação da família C, como C, C#, Go, Java, JavaScript, PHP ou Python.
Os documentos normalmente armazenam informações sobre um objeto, bem como qualquer informação relacionada a esse objeto. Os documentos relacionados são agrupados em coleções. As coleções relacionadas são agrupadas e armazenadas em um banco de dados.
Vamos discutir alguns dos conceitos básicos de um documento. Cada documento começa e termina com chaves.
1{
2}
Dentro desses colchetes, você encontrará um conjunto não ordenado de pares de campo/valor separados por vírgulas.
1{
2 field: value,
3 field: value,
4 field: value
5}
Os campos são strings que descrevem as partes de dados que estão sendo armazenadas.
Os valores podem ser qualquer um dos tipos de dados BSON. BSON tem uma variedade de tipos de dados, incluindo Duplo, String, Objeto, Array, Dados binários, ObjectId, Booleano, Data, Nulo, Expressão regular, JavaScript, JavaScript (com escopo), número inteiro de 32 bits, Timestamp, número inteiro de 64 bits, Decimal 128, Chave Mín. e Chave Máx. Com todos esses tipos disponíveis para uso, você tem o poder de modelar seus dados conforme eles existem no mundo real.
Todo documento é necessário para ter um campo chamado _id. O valor de _id deve ser exclusivo para cada documento em uma coleção, é imutável e pode ser de qualquer tipo que não seja uma array.

Documentos de exemplo

Ok, já chega de definições. Vamos dar uma olhada em um exemplo real e comparar como modelamos os dados no SQL e no MongoDB.

Armazenando as informações de Leslie

Digamos que precisamos armazenar informações sobre um usuário chamado Leslie. Armazenaremos suas informações de contato, incluindo seu nome, sobrenome, número de telefone celular e cidade. Também armazenaremos algumas informações adicionais sobre ela, incluindo localização, hobbies e histórico profissional.

Armazenando informações de contato

Vamos começar com as informações de contato de Leslie. Ao utilizar SQL, criaremos uma tabela denominada Users. Podemos criar colunas para cada informação de contato que precisamos armazenar: nome, sobrenome, número de telefone celular e cidade. Para garantir que tenhamos uma maneira única de identificar cada linha, incluiremos uma coluna de ID.
Usuários
IDfirst_namelast_namecelularCidade
1LeslieYepp8125552344Pawnee
Agora vamos armazenar essas mesmas informações no MongoDB. Podemos criar um novo documento para Leslie onde adicionaremos pares de campo/valor para cada informação de contato que precisamos armazenar. Usaremos _id para identificar exclusivamente cada documento. Armazenaremos este documento em uma coleção chamada Users.
Usuários
1{
2 "_id": 1,
3 "first_name": "Leslie",
4 "last_name": "Yepp",
5 "cell": "8125552344",
6 "city": "Pawnee"
7}

Armazenamento de latitude e longitude

Agora que armazenamos as informações de contato de Leslie, vamos armazenar as coordenadas de sua localização atual.
Ao usar SQL, precisaremos fazer a divisão da latitude e da longitude entre duas colunas.
Usuários
IDfirst_namelast_namecelularCidadelatitudelongitude
1LeslieYepp8125552344Pawnee39.170344-86.536632
O MongoDB tem um tipo de dados de array, então podemos armazenar a latitude e longitude juntos em um único campo.
Usuários
1{
2 "_id": 1,
3 "first_name": "Leslie",
4 "last_name": "Yepp",
5 "cell": "8125552344",
6 "city": "Pawnee",
7 "location": [ -86.536632, 39.170344 ]
8}
Dica bônus: o MongoDB tem algumas maneiras integradas diferentes de visualizar dados de localização, incluindo o analisador de esquema no MongoDB Compass e os gráficos geoespaciais no MongoDB Charts. Gerei o mapa abaixo com apenas alguns cliques no MongoDB Charts.
Mapa da localização de Leslie

Armazenando listas de informações

Estamos armazenando com sucesso as informações de contato e a localização atual de Leslie. Agora vamos armazenar os hobbies.
Ao usar SQL, podemos optar por adicionar mais colunas à tabela Usuários. No entanto, como um único usuário pode ter muitos hobbies (o que significa que precisamos representar um relacionamento de um para muitos), é mais provável que criemos uma tabela separada apenas para os hobbies. Cada linha da tabela conterá informações sobre um hobby de um usuário. Quando precisarmos recuperar os hobbies de Leslie, uniremos a tabela Users e nossa nova tabela Hobbies.
Hobbies
IDuser_idhobby
101scrapbooking
111comer waffles
121trabalhar
Como o MongoDB suporta arrays, podemos simplesmente adicionar um novo campo chamado "hobbies" ao nosso documento existente. A array pode conter quantos hobbies precisarmos (supondo que não excedamos o 16 megabyte document size limit). Quando precisamos recuperar os hobbies de Leslie, não precisamos fazer uma junção dispendiosa para reunir os dados; podemos simplesmente recuperar seu documento na coleçãoUsers.
Usuários
1{
2 "_id": 1,
3 "first_name": "Leslie",
4 "last_name": "Yepp",
5 "cell": "8125552344",
6 "city": "Pawnee",
7 "location": [ -86.536632, 39.170344 ],
8 "hobbies": ["scrapbooking", "eating waffles", "working"]
9}
Digamos que também precisamos armazenar o histórico de trabalho de Leslie.
Assim como fizemos com hobbies, é provável que criemos uma tabela separada apenas para informações do histórico de trabalho. Cada linha na tabela conterá informações sobre um trabalho para um usuário.
JobHistory
IDuser_idjob_titleyear_started
201"Diretor Adjunto"2004
211"Conselheiro municipal"2012
221"Diretor, Serviço de Parques Nacionais, Filial Meio-Oeste"2014
Até agora neste artigo, usamos arrays no MongoDB para armazenar dados de geolocalização e uma lista de strings. Arrays podem conter valores de qualquer tipo, incluindo objetos. Vamos criar um documento para cada tarefa que Leslie ocupou e armazenar esses documentos em um array.
Usuários
1{
2 "_id": 1,
3 "first_name": "Leslie",
4 "last_name": "Yepp",
5 "cell": "8125552344",
6 "city": "Pawnee",
7 "location": [ -86.536632, 39.170344 ],
8 "hobbies": ["scrapbooking", "eating waffles", "working"],
9 "jobHistory": [
10 {
11 "title": "Deputy Director",
12 "yearStarted": 2004
13 },
14 {
15 "title": "City Councillor",
16 "yearStarted": 2012
17 },
18 {
19 "title": "Director, National Parks Service, Midwest Branch",
20 "yearStarted": 2014
21 }
22 ]
23}

Armazenando informações de Ron

Agora que decidimos como armazenaremos informações sobre nossos usuários em tabelas e documentos, vamos armazenar informações sobre Ron. Ron terá quase todas as mesmas informações que Leslie. No entanto, Ron faz o possível para não ser localizado, então ele não armazenará sua localização no sistema.
Ron grita "Apague todas as fotos do Ron!" para o tablet

Ignorando dados de localização no SQL

Vamos começar examinando como armazenar as informações do Ron nas mesmas tabelas que usamos para as informações da Leslie. Ao usar SQL, precisamos inserir um valor para cada célula da tabela. Representaremos a falta de dados de localização de Ron com NULL. O problema de usar NULL é que não fica claro se os dados não existem ou se são desconhecidos, por isso muitas pessoas desencorajam o uso de NULL.
Usuários
IDfirst_namelast_namecelularCidadelatitudelongitude
1LeslieYepp8125552344Pawnee39.170344-86.536632
2RonSwandaughter8125559347PawneeZeroZero
Hobbies
IDuser_idhobby
101scrapbooking
111comer waffles
121trabalhar
132marcenaria
142pesca
JobHistory
IDuser_idjob_titleyear_started
201"Diretor Adjunto"2004
211"Conselheiro municipal"2012
221"Diretor, Serviço de Parques Nacionais, Filial Meio-Oeste"2014
232"Diretor"2002
242"CEO, Kinda Good Building Company"2014
252"superintendente, Parque Nacional de Pawnee"2018

Ignorando dados de localização no MongoDB

No MongoDB, temos a opção de representar a falta de dados de localização de Ron de duas maneiras: podemos omitir o campo location do documento ou podemos definir location como null. As melhores práticas sugerem omitirmos o campo location para economizar espaço. Você pode escolher se deseja que os campos omitidos e os campos definidos como null representem coisas diferentes em seus aplicativos.
Usuários
1{
2 "_id": 2,
3 "first_name": "Ron",
4 "last_name": "Swandaughter",
5 "cell": "8125559347",
6 "city": "Pawnee",
7 "hobbies": ["woodworking", "fishing"],
8 "jobHistory": [
9 {
10 "title": "Director",
11 "yearStarted": 2002
12 },
13 {
14 "title": "CEO, Kinda Good Building Company",
15 "yearStarted": 2014
16 },
17 {
18 "title": "Superintendent, Pawnee National Park",
19 "yearStarted": 2018
20 }
21 ]
22}

Armazenando as informações de Lauren

Digamos que estejamos satisfeitos com nossos modelos de dados e decidamos lançar nossos aplicativos usando-os.
Em seguida, descobrimos que precisamos armazenar informações sobre um novo usuário: Lauren Burhug. Ron é seu professor de administração pública no quarto ano. Muitas das informações que precisamos armazenar sobre Lauren são as mesmas que armazenamos sobre Leslie e Ron: nome, sobrenome, cidade e hobbies. No entanto, Lauren não tem telefone celular, dados de localização ou histórico de trabalho. Também descobrimos que precisamos armazenar uma nova informação: sua escola.

Armazenando novas informações em SQL

Vamos começar armazenando as informações de Lauren nas tabelas SQL, pois elas já existem.
Usuários
IDfirst_namelast_namecelularCidadelatitudelongitude
1LeslieYepp8125552344Pawnee39.170344-86.536632
2RonSwandaughter8125559347PawneeZeroZero
3LaurenBurhugZeroPawneeZeroZero
Hobbies
IDuser_idhobby
101scrapbooking
111comer waffles
121trabalhar
132marcenaria
142pesca
153futebol
Temos duas opções para armazenar informações sobre a escola de Lauren. Podemos optar por adicionar uma coluna à tabela Usuários existente ou podemos criar uma nova tabela. Digamos que optamos por adicionar uma coluna chamada "escola" à tabela Usuários. Dependendo de nossos direitos de acesso ao banco de dados, talvez precisemos conversar com o DBA e convencê-lo a adicionar o campo. Muito provavelmente, o banco de dados precisará ser retirado, a coluna "escola" precisará ser adicionada, os valores NULL serão armazenados em todas as linhas da tabela Usuários onde um usuário não tem uma escola e o banco de dados precisará ser trazido de volta.

Armazenando novas informações no MongoDB

Vamos examinar como podemos armazenar as informações da Lauren no MongoDB.
Usuários
1{
2 "_id": 3,
3 "first_name": "Lauren",
4 "last_name": "Burhug",
5 "city": "Pawnee",
6 "hobbies": ["soccer"],
7 "school": "Pawnee Elementary"
8}
Como você pode ver acima, adicionamos um novo campo chamado "escola" ao documento de Lauren. Não precisamos fazer nenhuma modificação no documento de Leslie ou no documento de Ron quando adicionarmos o novo campo "escola" ao documento de Lauren. O MongoDB possui um esquema flexível, então cada documento em uma coleção não precisa ter os mesmos campos.
Aqueles com anos de experiência no uso de bancos de dados SQL podem estar começando a entrar em pânico com a ideia de um esquema flexível. (Eu entrei em pânico quando me apresentaram a ideia).
April grita aterrorizada
Não entre em pânico! Essa flexibilidade pode ser extremamente valiosa à medida que os requisitos de seu aplicativo evoluem e mudam.
O MongoDB fornece validação de esquema para que você possa fazer o bloqueio do seu esquema tanto quanto desejar quando estiver pronto.

Mapeando Termos e Conceitos do SQL para o MongoDB

Agora que comparamos a modelagem de dados no SQL e no MongoDB, vamos ser um pouco mais explícitos com a terminologia. Vamos mapear termos e conceitos do SQL para o MongoDB.
Linha ⇒ Documento Uma linha mapeia aproximadamente para um documento. Como uma linha é mapeada para um documento
Dependendo de como você normalizou seus dados, as linhas em diversas tabelas podem ser mapeadas para um único documento. Em nossos exemplos acima, vimos que as linhas de Leslie nas tabelas Users, Hobbies e JobHistory foram mapeadas para um único documento.
Coluna ⇒ Campo
Uma coluna mapeia aproximadamente um campo. Por exemplo, quando modelamos os dados de Leslie, tínhamos uma coluna first_name na tabela Users e um campo first_name em um documento de usuário.
Como uma coluna mapeia para um campo
Tabela ➤ Coleção Uma tabela mapeia aproximadamente para uma coleção. Lembre-se de que uma coleção é um grupo de documentos. Continuando com o exemplo acima, nossa tabela Users mapeia para nossa coleção Users.
Como uma tabela é mapeada para uma coleção
Banco de dados ⇒ Banco de dados
O termo database é usado de forma bastante semelhante no SQL e no MongoDB. Grupos de tabelas são armazenados em bancos de dados SQL, assim como grupos de coleções são armazenados em bancos de dados MongoDB.
Banco de dados SQL e MongoDB database
Índice ⇒ Indice
Os índices oferecem uma funcionalidade bastante semelhante tanto no SQL quanto no MongoDB. Os índices são estruturas de dados que otimizam as consultas. Você pode pensar neles como um índice que se encontra no final de um livro; os índices informam ao banco de dados onde procurar informações específicas. Sem um índice, todas as informações em uma tabela ou coleção devem ser pesquisadas.
Índice SQL e índice do MongoDB
Os novos usuários do MongoDB geralmente esquecem o quanto os índices podem afetar o desempenho. Se você tiver uma query que está demorando muito para ser executada, certifique-se de ter um índice para suportá-la. Por exemplo, se soubermos que normalmente pesquisaremos usuários pelo nome ou sobrenome, devemos adicionar um índice de texto nos campos de nome e sobrenome.
Lembre-se: os índices diminuem o desempenho de gravação, mas aceleram o desempenho de leitura. Para obter mais informações sobre índices, incluindo os tipos de índices compatíveis com o MongoDB, consulte o Manual do MongoDB.
Visualização ⇒ Visualização
As visualizações são bastante semelhantes tanto no SQL quanto no MongoDB. No MongoDB, uma visualização é definida por um pipeline de agregação. Os resultados da visualização não são armazenados - eles são gerados sempre que a visualização é consultada.
Visualização SQL e visualização do MongoDB
Para saber mais sobre visualizações, consulte o Manual do MongoDB.
O MongoDB adicionou suporte para visualizações materializadas sob demanda na versão 4.2. Para saber mais, consulte o Manual do MongoDB.
Junção ⇒ Incorporação
Quando você usa bancos de dados SQL, as junções são bastante comuns. Você normaliza seus dados para evitar duplicação de dados e o resultado é que normalmente você precisa juntar informações de várias tabelas para executar uma única operação em seu aplicativo
No MongoDB, incentivamos você a modelar seus dados de forma diferente. Nossa regra geral é que os dados que são acessados juntos devem ser armazenados juntos. Se você cria, lê, atualiza ou exclui com frequência uma parte dos dados em conjunto, provavelmente deve armazená-los juntos em um documento em vez de dividi-los em vários documentos.
Você pode usar a incorporação para modelar dados que podem ter sido divididos em tabelas separadas ao usar SQL. Quando modelamos os dados de Leslie para o MongoDB anteriormente, vimos que incorporamos o histórico de tarefa no documento de usuário dela em vez de criar um documento JobHistory separado.
Junção SQL e incorporação MongoDB
Para obter mais informações, consulte as páginas do Manual do MongoDB sobre modelagem de relacionamentos um-para-um com incorporação e modelagem de relacionamentos um-para-muitos com incorporação.
Junte-se ⇒ Referências de banco de dados
Conforme discutimos na seção anterior, a incorporação é uma solução comum para modelar dados no MongoDB que você pode ter dividido em uma ou mais tabelas em um banco de dados SQL.
Junção SQL e referência do banco de dados MongoDB
No entanto, às vezes, a incorporação não faz sentido. Digamos que quiséssemos armazenar informações sobre os empregadores de nossos usuários, como nomes, endereços e números de telefone. O número de usuários que podem ser associados a um empregador é ilimitado. Se incorporássemos informações sobre um empregador em um documento User , os dados do empregador poderiam ser replicados centenas ou talvez milhares de vezes. Em vez disso, podemos criar uma nova coleção Employers e criar uma referência de banco de dados entre documentos User e documentos Employer.
Para obter mais informações sobre a modelagem de relacionamentos um-para-muitos com referências de banco de dados, consulte o Manual do MongoDB.
Left Outer Join ⇒ $lookup (pipeline de agregação)
Quando você precisar extrair todas as informações de uma tabela e juntá-las a quaisquer informações correspondentes em uma segunda tabela, poderá usar uma junção externa à esquerda no SQL.
O MongoDB tem um estágio semelhante a uma junção externa esquerda que você pode usar com o framework de agregação.
Para quem não está familiarizado com o framework de agregação, ele permite que você analise seus dados em tempo real. Usando o framework, você pode criar um pipeline de agregação que consiste em um ou mais estágios. Cada estágio transforma os documentos e passa a saída para o próximo estágio.
O $lookup é um estágio do framework de agregação que permite que você execute um left outer join a uma coleção não fragmentada no mesmo banco de dados.
Junção externa à esquerda SQL e MongoDB $lookup
Para obter mais informações, consulte as páginas do Manual do MongoDB sobre o framework de agregação e o $lookup.
A MongoDB University tem um curso gratuito fantástico sobre o pipeline de agregação que o orientará em detalhes no uso $lookup: MongoDB Aggregation.
Expressões de tabela comuns recursivas ⇒ $graphLookup (pipeline de agregação)*
Quando você precisa consultar dados hierárquicos, como o organograma de uma empresa no SQL, podemos usar expressões recursivas de tabelas comuns.
O MongoDB fornece um estágio de framework de agregação semelhante às expressões recursivas de tabela comum: $graphLookup. $graphLookup executa uma pesquisa recursiva em uma coleção.
Expressões de tabela comum recursiva SQL e $graphLookup
Para obter mais informações, consulte a página do Manual do MongoDB em $graphLookup e o curso gratuito da MongoDB University sobre framework de agregação.
ACID transaction de vários registros ⇒ ACID transaction de vários documentos
Por fim, vamos falar sobre as ACID transactions. As ACID transactions agrupam operações de banco de dados para que todas sejam bem-sucedidas ou nenhuma seja. No SQL, chamamos essas ACID transactions de vários registros e no MongoDB, chamamos ACID transactions de vários documentos.
Transação SQL e transação MongoDB
Para obter mais informações, consulte o Manual do MongoDB.

Embrulhar

Acabamos de abordar muitos conceitos e terminologia. Os três mapeamentos de termos que eu recomendo que você internalize ao começar a usar o MongoDB são:
  • As linhas mapeiam os documentos.
  • As colunas são mapeadas para os campos.
  • As tabelas mapeiam as coleções.
Criei o seguinte diagrama que você pode usar como referência no futuro, ao iniciar sua jornada usando o MongoDB.
Mapeamento de termos do SQL para o MongoDB
Fique atento à próxima publicação desta série, em que discutiremos as quatro principais razões pelas quais você deve usar o MongoDB.

Ícone do FacebookÍcone do Twitterícone do linkedin
Avalie esse Artigo
star-empty
star-empty
star-empty
star-empty
star-empty
Relacionado
Artigo

Orquestração do MongoDB com o Spring e Atlas Kubernetes Operator


Jun 12, 2024 | 13 min read
Tutorial

Compressão de rede MongoDB: uma situação em que todos ganham


Aug 13, 2024 | 6 min read
Início rápido

Como criar um aplicativo CRUD com MongoDB, Quarkus e GraalVM


Aug 29, 2024 | 7 min read
Início rápido

Introdução ao MongoDB e Mongoose


Aug 05, 2024 | 9 min read
Sumário