E aí, jovem escoteiro, tudo beleza!? Se você chegou até aqui, provavelmente já viu nossas outras séries de: PHP para iniciantes e Programação Orientada a Objetos com PHP. Ainda não? Então dá uma conferida.

Nessa série vamos aprender a trabalhar com o PHP utilizando o MongoDB, um banco de dados não relacional, orientado a documentos, leve, simples e que você com certeza vai amar.

Antes de iniciarmos, vamos entender o que é um banco de dados, qual a diferença entra bancos de dados relacionais e não relacionais e o que é o MongoDB.

Persistência de dados

Imagine que você está desenvolvendo um software em PHP para um pequeno comércio do seu bairro, esse software gerenciará todas as vendas que esse pequeno comércio realiza. Mas, para que a informação de uma venda seja armazenada, o que precisamos saber?

• Quem comprou (Cliente)
• Quem vendeu (Vendedor / Atendente)
• O que foi comprado (Produtos)
• Quando foi comprado (Data da compra)
• Qual foi o valor pago (Preço no momento da venda)
• Etc.

Beleza, já sabemos o que armazenas, mas aí vem a pergunta de 1 milhão de dólares: "Onde vou armazenar isso?"

Em nosso curso PHP para iniciantes, você aprender a Ler e gravar arquivos com o PHP, você deve estar tentado a responder: "É só criar alguns arquivos de texto que está tudo bem", mas será mesmo?

Arquivos de texto são muito úteis para diversas ações que fazemos em nossos softwares, mas quando passamos a armazenar dados estruturados, que requerem um nível de segurança maior e onde vai haver concorrência (vários processos tentando acessar a informação ao mesmo tempo) ele já não se mostra uma boa opção. Pensando nisso, foram criados os bancos de dados e consequentemente os SGBD (Sistemas Gerenciadores de Bancos de Dados), nele podemos definir uma estrutura, definir quem pode acessar e realizar operações de inserção de dados, alteração de dados, deleção de dados, leitura de dados, alteração de estrutura de dados, etc... Além disso ele permite que tenhamos diversas conexões simultâneas.

Um SGBD é um software extremamente complexo (em sua construção, mas não em sua utilização) que nos auxilia a gerenciar nossos bancos de dados. Por outro lado, o banco de dados normalmente é apenas um arquivo ou um conjunto de arquivos onde nossos dados estão, ou serão, armazenados. Na maioria das vezes não é possível acessar os dados do banco de dados sem a utilização do SGBD.

Uma analogia bem simplória é: Pense num arquivo .rar. Você pode inserir diversos dados dentro de um arquivo .rar, mas para inserir, modificar ou ler esses dados, será necessário usar um software (Ex.: WINRAR) que gerenciará todas essas operações.

Temos no mercado, à nossa disposição, diversos SGBD (Sistemas Gerenciadores de Bancos de Dados), sendo os mais populares: MySQL, Oracle, PostgreSQL, MongoDB, Redis, SQL Server, SQLite, etc.

Modelo relacional x NoSQL

Cada SGBD pode utilizar uma ou mais abordagens para gerenciar nossos dados. As formas mais populares de gerenciamento são o Modelo Relacional e o Modelo não relacional (NoSQL).

No modelo relacional nós devemos modelar nossos bancos de dados em tabelas onde cada tabela representar uma entidade do mundo real, exemplo:

• Vendedores
• Produtos
• Clientes
• Fornecedores
• Etc.

Podemos pensar uma tabela do banco de dados como uma planilha do Excel, com linhas e colunas. Cada linha representa um registro da tabela e cada coluna uma propriedade que aquela entidade tem, exemplo:

Tabela: Fornecedores

Tabela: Produtos

Nos exemplos acima é possível perceber que registros da tabela Fornecedores podem se relacionar com registros da tabela Produtos. Isso se chama "relacionamento" (um nome bem sugestivo). Essa característica dos bancos relacionais são uma enorme vantagem para vários tipos de sistemas.

Pegando o exemplo acima, imagine que tivéssemos 1.000.000 de produtos cadastrados na tabela Produtos. Se não utilizássemos relacionamentos teríamos que copiar todos os dados dos fornecedores em cada registro da tabela Produtos, o que ocuparia muito espaço em disco. Utilizando relacionamento, não se torna necessário copiar todos os dados, basta fazer uma referência ao registro. Que nesse caso fizemos pelo ID (código identificador único do registro).

Não vamos aprofundar muito em bancos de dados Relacionais, a ideia era só dar uma leve pincelada.

No MongoDB, que utiliza o modelo não relacional, não temos o conceito de tabelas, mas sim de coleções. Cada coleção armazena um conjunto de documentos representados normalmente em formado JSON ou BSON (Bin­ary JSON), utilizando uma estrutura chave/valor. Exemplo:

{
  "_id": {
    "$oid": "6343f8e85ccb38eb9806093d"
  },
  "nome": "Feijão Carioquinha XPTO",
  "preco": {
    "$numberDecimal": "9.90"
  },
  "data_validade": {
    "$date": {
      "$numberLong": "1672444800000"
    }
  },
  "data_compra": {
    "$date": {
      "$numberLong": "1665360000000"
    }
  },
  "fornecedor": {
    "nome": "Jurubeba Distribuidora de Alimentos",
    "cnpj": "321.654.987/4321-99",
    "telefone": "(21) 1234-1234",
    "email": "jurubeba@email.com"
  }
}

Vamos simplificar um pouco para melhorar o entendimento

{
  "_id": "6343f8e85ccb38eb9806093d",
  "nome": "Feijão Carioquinha XPTO",
  "preco": "9.90",
  "data_validade": "2022-12-31",
  "data_compra": "2022-10-10",
  "fornecedor": {
    "nome": "Jurubeba Distribuidora de Alimentos",
    "cnpj": "321.654.987/4321-99",
    "telefone": "(21) 1234-1234",
    "email": "jurubeba@email.com"
  }
}

No exemplo acima, veja que na coleção "Produtos" temos um documento referente ao produto "Feijão Carioquinha XPTO" e ele carrega consigo os dados do fornecedor. Isso tem efeitos colaterais positivos e negativos.

Se por um lado o espaço em disco utilizado é ligeiramente maior, diferente dos bancos relacionais, a característica dinâmica do MongoDB te permite salvar cada documento com uma estrutura completamente diferente, com isso você poderia salvar apenas o nome e o e-mail se julgasse interessante, ao invés de salvar todos os dados do fornecedor.

Exemplo (simplificado):

[
  {
    "_id": "6343f8e85ccb38eb9806093d",
    "nome": "Feijão Carioquinha XPTO",
    "preco": "9.90",
    "data_validade": "2022-12-31",
    "data_compra": "2022-10-10",
    "fornecedor": {
      "nome": "Jurubeba Distribuidora de Alimentos",
      "cnpj": "321.654.987/4321-99",
      "telefone": "(21) 1234-1234",
      "email": "jurubeba@email.com"
    }
  },
  {
    "_id": "6343fba85ccb38eb9806093f",
    "nome": "Refrigerante Doce de Verdade",
    "preco": "7.49",
    "data_validade": "2022-12-31",
    "data_compra": "2022-10-10",
    "fornecedor": {
      "nome": "Coca Coca do Brasil",
      "email": "cocacoca@email.com"
    }
  }
]

Perceba que na coleção acima, o segundo documento não tem exatamente a mesma estrutura do primeiro, mas o MongoDB não está nem aí para isso, ele te dá essa liberdade. E isso é muito interessante pelo seguinte:

Todos os produtos têm a mesma estrutura? Pense em como você descreveria em uma planilha do Excel os seguintes produtos:

• Computador Gamer Ryzen 5 + RTX 3090
• Feijão Carioquinha - 1Kg
• Suco de Uva - 1L
• Ovos (Dúzia)
• E-book: O pequeno príncipe

Note que cada um desses produtos tem características individuais. Além do nome, preço, etc... Você teria que armazenar no banco de dados:

• Computador Gamer
  • Processador
  • Memória
  • HD, SSD ou Ambos
  • Placa de vídeo
  • Etc.
• Feijão
  • Peso
  • Tipo
• Suco de Uva
  • Volume
  • Se é caixa ou garrafa
  • Se é com ou sem açúcar
• Etc.

E o E-book, que é um produto digital?

O que eu quero que você entenda é que não existe "Bala de Prata". Não adianta ficar defendente tecnologia como sendo a melhor ou pior. Todas as ferramentas nascem com um propósito, para resolver um tipo específico de problema. E o exemplo acima mostrou isso.

Se você chegou até aqui sem entender muita coisa do que foi dito acima, pode ficar tranquilo, isso é normal, nos próximos posts veremos alguns exemplos práticos aí tudo vai ficar muito mais claro.

Espero você lá, escoteiro!