Mapeando Termos e Conceitos do SQL para o MongoDB
Avalie esse Artigo
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:
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 é.
Este é o Ron. Ron gosta de mulheres fortes, bacon e de ficar fora da rede.
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.
Infelizmente, vejo três grandes problemas com o plano dele:
- O correio tradicional é muito mais lento do que publicar a avaliação no Yelp, onde ela estará instantaneamente disponível para qualquer pessoa ler.
- 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.
- Ninguém mais se beneficiará da sua avaliação. (É exatamente esse tipo de avaliação que eu gostaria de encontrar na Amazon!)
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.
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.
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.
Em vez de tabelas, o MongoDB armazena dados em documentos. Não, Clippy, não estou falando de documentos do Microsoft Word.
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.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.
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.
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
| ID | first_name | last_name | celular | Cidade |
|---|---|---|---|---|
| 1 | Leslie | Yepp | 8125552344 | Pawnee |
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 }
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
| ID | first_name | last_name | celular | Cidade | latitude | longitude |
|---|---|---|---|---|---|---|
| 1 | Leslie | Yepp | 8125552344 | Pawnee | 39.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.
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
| ID | user_id | hobby |
|---|---|---|
| 10 | 1 | scrapbooking |
| 11 | 1 | comer waffles |
| 12 | 1 | trabalhar |
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ção
Users.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.
| ID | user_id | job_title | year_started |
|---|---|---|---|
| 20 | 1 | "Diretor Adjunto" | 2004 |
| 21 | 1 | "Conselheiro municipal" | 2012 |
| 22 | 1 | "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 }
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.
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
| ID | first_name | last_name | celular | Cidade | latitude | longitude |
|---|---|---|---|---|---|---|
| 1 | Leslie | Yepp | 8125552344 | Pawnee | 39.170344 | -86.536632 |
| 2 | Ron | Swandaughter | 8125559347 | Pawnee | Zero | Zero |
Hobbies
| ID | user_id | hobby |
|---|---|---|
| 10 | 1 | scrapbooking |
| 11 | 1 | comer waffles |
| 12 | 1 | trabalhar |
| 13 | 2 | marcenaria |
| 14 | 2 | pesca |
JobHistory
| ID | user_id | job_title | year_started |
|---|---|---|---|
| 20 | 1 | "Diretor Adjunto" | 2004 |
| 21 | 1 | "Conselheiro municipal" | 2012 |
| 22 | 1 | "Diretor, Serviço de Parques Nacionais, Filial Meio-Oeste" | 2014 |
| 23 | 2 | "Diretor" | 2002 |
| 24 | 2 | "CEO, Kinda Good Building Company" | 2014 |
| 25 | 2 | "superintendente, Parque Nacional de Pawnee" | 2018 |
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 }
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.
Vamos começar armazenando as informações de Lauren nas tabelas SQL, pois elas já existem.
Usuários
| ID | first_name | last_name | celular | Cidade | latitude | longitude |
|---|---|---|---|---|---|---|
| 1 | Leslie | Yepp | 8125552344 | Pawnee | 39.170344 | -86.536632 |
| 2 | Ron | Swandaughter | 8125559347 | Pawnee | Zero | Zero |
| 3 | Lauren | Burhug | Zero | Pawnee | Zero | Zero |
Hobbies
| ID | user_id | hobby |
|---|---|---|
| 10 | 1 | scrapbooking |
| 11 | 1 | comer waffles |
| 12 | 1 | trabalhar |
| 13 | 2 | marcenaria |
| 14 | 2 | pesca |
| 15 | 3 | futebol |
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.
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).
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.
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. 
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
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
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.
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.
Banco de dados ⇒ Banco de dados
O termo
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.
Í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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
Fique atento à próxima publicação desta série, em que discutiremos as quatro principais razões pelas quais você deve usar o MongoDB.