JSON em banco de dados Quando alguém perguntar para você por que você deseja utilizar um banco de dados documental e por que você quer usar JSON sua resposta certamente deve incluir escalabilidade horizontal distribuída são coisas que os bancos de dados relacionais têm uma certa dificuldade em entregar para a gente, então, horizontal e distribuição. E pensando no modelo de dados, como a gente já começou a perceber, existe uma flexibilidade muito grande, o esquema de dados admite variações e facilita a evolução da aplicação ao longo do tempo. Não requer uma pessoa DBA para fazer uma alteração no esquema de dados, isso é bem interessante e, consequentemente, isso é uma evolução facilitada do modelo de dados. Então, geralmente, os motivos principais para a gente adotar uma modelagem documental e, consequentementeemente trabalhar em JSON, tem esses três elementos. E ainda que eu também não mencionei a aceleração no processo de desenvolvimento, porque a gente pensa na aplicação em orientação a objetos, nosso código orientado a objetos, se nós estamos ali abstraindo, fazendo um código um objeto, nada mais natural do que persistir esse objeto da mesma maneira como ele foi idealizado pela pessoa desenvolvedora. A gente salva o tempo de fazer o mapeamento objeto-relacional, quando está usando orientação-objetos e um banco de dados relacional. e um banco de dados relacional. Vamos observar juntos aqui este exemplo, novamente, eu estou trazendo aqui o evento de um pedido, o nosso order number, que tem um cliente, que tem itens que foram comprados e que foram pagos por um método de pagamento aqui, um cartão. Então, se nós fôssemos fazer essa modelagem deste evento de negócio em relacional, nós vamos ter uma tabela de pedidos, que é Orders, nós vamos ter uma tabela de clientes, que é Customers, nós vamos ter os itens dos pedidos guardados na Order Lines, com uma relação aí para a tabela de produto também, e o tipo do pagamento. Agora, olha só como ficaria interessante fazer tudo isso. Então, aqui a gente tem cinco tabelas, cinco operações de escrita, pelo menos cinco operações de leitura, quando a gente precisar recuperar esse pedido. Então, quando nós fizermos este exercício, o nosso registro em relacional, vai ficar exatamente com essa aparência. Então, o nosso documento de pedido, aqui eu tenho um pedido para um cliente, então aqui já tem um relacionamento um para um, sendo estabelecido um pedido para um cliente, ou melhor, é que este pedido tem um cliente, mas um cliente vai poder ter muitos pedidos. E ali no lineItems, a gente tem a abertura do array, então, segundo relacionamento sendo estabelecido, que uma ordem, um pedido, tem muitos itens, muitas linhas de pedido, segundo relacionamento. muitas linhas de pedidos segundo o relacionamento. E mais ali no final, no payment, significa que esse pedido tem um método de pagamento, que nesse caso foi um cartão. Então a gente vai fazendo a modelagem de maneira quase que natural, quase que intuitiva, e pega essa sofisticação de estruturas complexas, para representar aqui os pagamentos, que é um objeto, os itens, que é um array de outros objetos e consequentemente os relacionamentos vão sendo naturalmente feitos. Aqui um ponto interessante, entidade e relacionamento permanece na modelagem documental, porque como vocês estão vendo aqui, eu continuo com os elementos fundamentais de negócios, entidades, pedido, cliente, item e pagamento e os respectivos relacionamentos estão sendo refletidos aqui no modelo de Eisson.