‫Narrador: Uma das etapas mais
‫importantes na construção de aplicativos com uso intensivo de dados é
‫modelar de fato todos esses dados no MongoDB.
‫E é sobre isso que falaremos nesta palestra.
‫Portanto, é realmente crucial que você siga até
‫o fim, mesmo no início, é muito para aceitar. Tudo bem.
‫De qualquer forma, vamos começar agora.
‫Agora, a modelagem de dados é provavelmente um conceito muito novo para você.
‫Portanto, antes de
‫começarmos; vamos deixar claro sobre o que vamos falar.
‫Portanto, modelagem de dados é o processo de pegar dados não
‫estruturados gerados por um cenário do mundo real e, em
‫seguida, estruturá-los em um modelo de dados lógico em um
‫banco de dados.
‫E fazemos isso de acordo com
‫um conjunto de critérios que aprenderemos neste vídeo.
‫Por exemplo; digamos que queremos projetar um modelo
‫de dados de loja online.
‫Haverá inicialmente uma tonelada de dados não estruturados de que
‫sabemos que precisamos.
‫Direito.
‫Coisas como produtos, categorias,
‫pedidos de clientes, carrinhos de compras, fornecedores.
‫E assim por diante.
‫Nosso objetivo com a modelagem de dados é então estruturar
‫esses dados de uma maneira lógica.
‫Refletindo os relacionamentos do mundo real
‫que existem entre alguns desses conjuntos de dados.
‫Um pouco como você pode ver neste exemplo.
‫E é claro que isso é apenas um tipo de situação imaginária, mas
‫essa é a ideia.
‫Direito.
‫Agora, muitos desenvolvedores de back-end dizem que a modelagem de dados
‫é onde devemos pensar mais.
‫Essa é a parte mais exigente de
‫construir um aplicativo inteiro.
‫Porque realmente nem sempre é direto.
‫E às vezes simplesmente não há respostas certas.
‫Portanto, não apenas uma maneira correta de estruturar os dados.
‫Mas de qualquer forma, farei o meu melhor para estabelecer o
‫processo neste vídeo.
‫E para isso vamos passar por quatro etapas.
‫Então, na primeira etapa; aprendemos como identificar diferentes
‫tipos de relacionamento entre os dados.
‫Então,
‫vamos entender a diferença entre
‫referência ou normalização e incorporação ou desnormalização.
‫Na próxima e
‫mais importante etapa; Mostrarei minha estrutura para
‫decidir se devemos incorporar documentos
‫ou fazer referência a outros
‫documentos com base em alguns fatores diferentes.
‫Além disso, temos que falar rapidamente sobre
‫os diferentes tipos de referência.
‫Porque isso é importante se esse for o tipo de
‫design que escolhemos para nossos dados.
‫Portanto, esta vai ser na verdade uma aula bastante teórica.
‫Mas também absolutamente essencial para o seu progresso como
‫desenvolvedor de back-end.
‫Porque a maneira como projetamos dados, a maneira como modelamos nossos
‫dados pode fazer ou quebrar todo o nosso aplicativo.
‫E haverá muitos exemplos ao longo do caminho para
‫tornar esse processo mais fácil.
‫Tudo bem.
‫E a primeira coisa sobre
‫a qual falaremos são os diferentes tipos
‫de relacionamento que podem existir entre os dados.
‫Portanto, existem três grandes tipos de relacionamento.
‫Um para um, um para muitos e muitos para muitos.
‫E vou usar um aplicativo
‫de filme como exemplo neste slide.
‫OK?
‫Portanto, primeiro uma relação um para um
‫entre os dados é
‫basicamente quando um campo só pode ter um valor.
‫Portanto, em nosso exemplo de aplicação de filme; um filme só
‫tem um nome.
‫E, portanto, este é um
‫exemplo simples de relacionamento um para um.
‫Mas esses relacionamentos não são realmente importantes em
‫termos de modelagem de dados.
‫Agora, os relacionamentos mais
‫importantes são um para muitos relacionamentos.
‫E eles são tão importantes que no
‫MongoDB realmente distinguimos entre três tipos de
‫relacionamentos um para muitos.
‫Um para alguns, um para muitos e um para uma tonelada ou um
‫milhão ou algo assim. Portanto, a diferença aqui é
‫baseada na quantidade relativa de muitos. Tudo bem.
‫Portanto, um exemplo para um relacionamento de um
‫para alguns é que um filme pode ganhar muitos prêmios, mas na verdade apenas alguns.
‫Portanto, o filme não vai ganhar mil prêmios, mas
‫pode ganhar alguns.
‫E então este é um relacionamento típico de um para poucos.
‫Portanto, você vê que, em geral, um relacionamento de um
‫para muitos significa que um documento pode estar relacionado a muitos outros documentos.
‫Agora, isso pode parecer um pouco abstrato sem os dados JSON, mas
‫esse é realmente o propósito aqui.
‫Eu só quero mostrar a vocês uma
‫visão geral conceitual desses diferentes tipos de relacionamento.
‫De qualquer forma, qualquer relacionamento um para muitos
‫um documento pode se relacionar a centenas ou milhares
‫de outros documentos.
‫Por exemplo; um filme pode ter milhares de
‫comentários em nosso aplicativo.
‫E, portanto, este não é realmente um relacionamento de um para poucos, mas
‫de um para muitos. OK?
‫E, finalmente, temos o relacionamento de um para outro.
‫Imagine que queremos implementar alguma funcionalidade de registro
‫em nosso aplicativo. Então, basicamente, para saber exatamente
‫o que está acontecendo em nosso servidor.
‫Esses logs podem facilmente crescer para milhões de documentos.
‫E então este é um exemplo
‫muito típico de um relacionamento de um para outro.
‫E a diferença entre muitos e uma tonelada é,
‫claro, um pouco confusa, mas pense que se algo pode crescer
‫quase até o infinito, então é definitivamente uma
‫relação de um para uma tonelada.
‫Portanto, novamente, os relacionamentos de um para muitos
‫são os mais importantes a se conhecer.
‫Por falar nisso; em bancos de
‫dados relacionais, há apenas um para muitos, sem
‫quantificar o quanto esse número realmente é.
‫Em bancos de dados MongoDB,
‫porém, é uma diferença extremamente importante.
‫Porque é um dos fatores que usaremos para
‫decidir se devemos desnormalizar ou normalizar
‫os dados, como você aprenderá um pouco mais tarde.
‫De qualquer forma, o menor tipo de relacionamento é o de muitos para
‫muitos em que um filme pode ter muitos atores.
‫Mas, ao mesmo tempo, um ator pode atuar em muitos filmes.
‫E aqui o relacionamento basicamente segue em
‫ambas as direções.
‫Onde antes, nos outros tipos, era
‫apenas em uma direção.
‫Por exemplo, um filme pode ter muitas críticas, mas uma
‫específica é apenas para aquele filme. Direito.
‫E o mesmo vale para os prêmios.
‫Portanto, um prêmio específico, como o de
‫melhor ator, vai para apenas um filme, não para vários.
‫Mas com filmes e atores é realmente diferente.
‫Então, novamente, um filme é estrelado por muitos atores, mas
‫um ator representa muitos filmes e,
‫portanto, é um relacionamento de muitos para muitos.
‫OK.
‫Portanto, mantenha tudo isso em mente enquanto avançamos
‫nesta palestra.
‫E provavelmente o aspecto mais importante que precisamos aprender
‫sobre os bancos de dados MongoDB é referenciar
‫e incorporar dois conjuntos de dados.
‫E na verdade já falamos
‫um pouco sobre isso antes, mas vamos revisá-lo aqui
‫e ir um pouco mais fundo também.
‫Portanto, cada vez que temos dois
‫conjuntos de dados relacionados, podemos representar esses dados relacionados
‫em uma referência ou forma normalizada ou em uma forma incorporada ou desnormalizada.
‫E continuo usando os dois termos relacionados juntos, como
‫referência e normalização, porque você
‫os verá sendo usados
‫e, portanto, é importante que você os conheça.
‫De qualquer forma, no formulário referenciado mantemos dois conjuntos de
‫dados relacionados e todos os documentos separados.
‫Então, novamente, todos os dados estão bem separados, o
‫que é exatamente o que normalizado significa.
‫Continuando, o exemplo do banco de dados de filmes anterior,
‫teríamos um documento de filme e um documento de
‫ator para cada ator. Agora, como faríamos a conexão
‫entre o filme e os atores para que mais tarde em nosso
‫aplicativo possamos mostrar quais atores atuaram em um determinado filme.
‫Porque se são todos documentos completamente diferentes o filme não
‫tem como saber sobre os atores. Direito.
‫Bem, é aí que entram os IDs.
‫Portanto, usamos os IDs de ator para criar referências no
‫documento do filme.
‫Conectando efetivamente filmes com atores.
‫Então, você vê que em um documento de filme temos uma matriz
‫onde armazenamos os IDs de todos os
‫atores para que, quando solicitamos dados sobre um determinado filme,
‫possamos identificar facilmente seus atores. Isso faz sentido?
‫Agora, esse tipo de referência é chamado de referência filho porque é
‫o pai, neste caso, o filme que faz
‫referência a seus filhos. Neste caso, os atores.
‫Então, estamos realmente criando algum tipo de hierarquia aqui. Direito.
‫Agora também há referência aos pais e falaremos
‫sobre isso um pouco mais tarde.
‫E, por falar nisso, em bancos de dados relacionais; todos os
‫dados são sempre representados na forma normalizada assim.
‫Mas em um banco de dados sem sequência
‫como o MongoDB, podemos desnormalizar os dados em uma
‫forma desnormalizada simplesmente incorporando o
‫documento relacionado diretamente ao documento principal.
‫Portanto, agora temos todos os dados relevantes
‫sobre os atores dentro de um documento principal do filme,
‫sem a necessidade de documentos, coleções e IDs separados.
‫Portanto, novamente, se escolhermos desnormalizar ou incorporar nossos dados, teremos um
‫documento principal contendo todos os dados principais, bem como
‫os dados relacionados. Tudo bem.
‫E o resultado disso é que nosso aplicativo precisará
‫de menos consultas ao banco de dados.
‫Porque podemos obter
‫todos os dados sobre filmes e atores
‫ao mesmo tempo, o que certamente aumentará nosso desempenho.
‫Agora, a desvantagem aqui é
‫que não podemos realmente consultar os dados incorporados por conta própria.
‫E então, se isso for um requisito para o
‫aplicativo, você terá que escolher um design normalizado,
‫já que estamos falando sobre prós e
‫contras da forma desnormalizada; vamos fazer o
‫mesmo com o design normalizado.
‫E basicamente é o oposto do
‫que acabamos de falar.
‫Portanto, há uma melhoria no desempenho
‫quando frequentemente precisamos consultar os dados relacionados por conta própria, porque
‫então podemos apenas consultar os dados de que precisamos
‫e nem sempre filmes e atores juntos.
‫Mas por outro lado; quando precisarmos realmente consultar
‫filmes e atores juntos, precisaremos
‫de muitas consultas ao banco de dados.
‫Portanto, primeiro a consulta para o filme e, a partir daí, também
‫precisaremos de uma consulta para o ator e
‫isso é claro funciona para a performance.
‫Portanto, ao projetar seu banco de dados; esse é o tipo de coisa que você
‫precisa ter em mente. Tudo bem.
‫E agora apenas como uma nota lateral; poderíamos, é claro, começar nosso processo
‫de pensamento com dados desordenados e
‫então chegar à conclusão de que é melhor
‫normalizar de fato os dados.
‫Portanto, ao pensar sobre nosso modelo de dados, essa maneira de
‫organizar os dados funciona, é claro, em ambas as formas.
‫Agora, como realmente decidimos se devemos normalizar
‫ou desnormalizar os dados?
‫Bem, isso é exatamente o que vamos aprender a seguir.
‫Então, quando temos dois conjuntos de dados relacionados; temos que decidir
‫se vamos incorporar os conjuntos de dados ou se vamos
‫mantê-los separados e referenciá-los
‫de um conjunto de dados para o outro.
‫E eu meio que desenvolvi essa
‫estrutura de decisão que vou mostrar onde usamos três critérios
‫para tomar essa decisão.
‫Primeiro, examinamos o tipo de relacionamento que
‫existe entre os conjuntos de dados.
‫Em segundo lugar, tentamos determinar o padrão de
‫acesso aos dados do conjunto de dados que queremos incorporar ou fazer referência.
‫E isso significa apenas analisar a frequência com que os dados são
‫lidos e gravados nesse conjunto de dados.
‫Em seguida, também examinamos algo que chamo de proximidade de dados.
‫E proximidade de dados é um termo que eu acabei de inventar,
‫mas o que significa é o quanto os dados estão realmente relacionados e
‫como queremos consultar os dados do banco de dados.
‫E isso fará mais sentido
‫quando falarmos sobre isso em um momento.
‫Agora, para realmente tomar a decisão; precisamos combinar
‫todos esses três critérios
‫e não apenas usar um deles isoladamente.
‫Então, por exemplo; só porque o critério número um diz
‫para incorporá-lo, não significa que não precisamos olhar
‫para os outros dois critérios.
‫Tudo bem e vamos começar com o tipo de relacionamento.
‫Normalmente, quando temos um relacionamento um para poucos, sempre incorporaremos
‫o conjunto de dados relacionado ao conjunto
‫de dados principal, como aprendemos no
‫último slide. Direito.
‫Agora em um relacionamento de um para muitos; as coisas estão
‫um pouco mais confusas, então não há problema em incorporar ou fazer referência.
‫Nesse caso, teremos de decidir de acordo
‫com os outros dois critérios.
‫Por outro lado, em uma relação de
‫um para uma tonelada ou de muitos para muitos, geralmente sempre
‫referenciamos os dados. Isso porque, se realmente
‫incorporássemos neste caso, poderíamos criar rapidamente um documento muito grande.
‫Mesmo ultrapassando potencialmente o máximo de 16 megabytes.
‫E então a solução para isso é referenciar
‫ou normalizar os dados. E como um exemplo rápido;
‫digamos que em nosso exemplo de banco
‫de dados de filmes, temos cerca de 100 imagens associadas a cada filme.
‫Portanto, poderíamos dizer que é um relacionamento de
‫um para muitos, mas vamos incorporar o conjunto de dados
‫ou devemos referenciá-los aqui. Bem, nós realmente não sabemos.
‫Então, vamos dar uma olhada nos outros dois critérios.
‫Portanto, o segundo é sobre padrões de acesso a dados, onde
‫é apenas uma descrição
‫sofisticada para avaliar se um
‫determinado conjunto de dados é principalmente escrito ou lido.
‫Portanto, se o conjunto de dados sobre o qual estamos decidindo for quase
‫todo lido e os dados não
‫forem muito atualizados, provavelmente devemos incorporar esse conjunto de dados.
‫Portanto, uma alta proporção de leitura / gravação significa apenas que
‫há muito mais leitura do que escrita.
‫E, novamente, um conjunto de dados como esse é um bom candidato
‫para incorporação.
‫A razão para isso é que, com a incorporação, precisamos apenas de
‫uma viagem ao banco de dados por consulta.
‫Já para referenciar, precisamos de duas viagens. Direito.
‫Portanto, se incorporarmos dados que são muito lidos; em
‫cada consulta, economizamos uma viagem ao
‫banco de dados, tornando todo o processo muito mais eficiente.
‫Portanto, acho que nosso exemplo de imagem de
‫filme seria um bom candidato para incorporação.
‫Porque uma vez que as 100 imagens são salvas
‫no banco de dados, elas não são
‫mais atualizadas porque não há realmente nada para atualizar
‫sobre uma imagem. Certo, então é
‫tudo sobre leitura e, portanto, com
‫base nesses critérios, incorporaríamos os documentos com imagens.
‫Por outro lado, se nossos dados são
‫muito atualizados, devemos considerar referenciar ou normalizar os dados.
‫Isso porque dá mais trabalho para o mecanismo de banco de
‫dados atualizar e incorporar um
‫documento do que um documento autônomo mais simples.
‫E já que nosso principal objetivo é o desempenho;
‫apenas normalizamos o conjunto de dados.
‫Em nosso exemplo, digamos que cada filme tenha muitas análises e
‫cada análise pode ser marcada como útil pelo usuário.
‫Portanto, cada vez que alguém clica nessa avaliação, nosso aplicativo
‫é útil. Precisamos
‫atualizar o documento correspondente.
‫E isso significa que os dados podem mudar o
‫tempo todo e, portanto, esse é um ótimo candidato para normalização.
‫Mais uma vez, porque não queremos consultar os filmes
‫o tempo todo se tudo o que realmente queremos atualizar são
‫as avaliações, marcando-as como úteis.
‫Ok, isso faz sentido?
‫E, finalmente, o último critério eu chamo de proximidade de dados;
‫que é como uma medida de quanto os
‫dados estão relacionados. Portanto, se os
‫dois conjuntos de dados realmente pertencem intrinsecamente um ao
‫outro, provavelmente devem ser incorporados um ao outro.
‫Em nosso exemplo; todos os usuários podem ter muitos endereços de e-mail
‫em sua conta e, como estão intrinsecamente conectados
‫ao usuário, não há dúvidas de que os
‫e-mails devem ser incorporados ao documento.
‫Agora, se frequentemente precisamos consultar os dois conjuntos de dados sozinhos,
‫esse é um bom motivo para
‫normalizar os dados em dois conjuntos de dados separados.
‫Mesmo se eles estiverem intimamente relacionados.
‫Então imagine que em nosso aplicativo
‫temos um questionário onde os usuários têm que identificar um filme baseado em imagens.
‫Isso significa que vamos consultar muitas imagens por
‫conta própria.
‫Portanto, sem necessariamente consultar os próprios filmes.
‫E assim, se aplicarmos este terceiro critério; chegamos
‫à conclusão de que devemos realmente normalizar o conjunto de
‫dados da imagem. Tudo bem.
‫Porque, novamente, se implementarmos essa funcionalidade de questionário; as
‫imagens serão consultadas sozinhas o tempo todo.
‫Então, tudo isso mostra que devemos realmente olhar
‫todos os três critérios juntos,
‫em vez de apenas um deles isoladamente.
‫Porque isso pode levar a decisões menos ideais.
‫E eu digo menos ideal em vez de
‫errado porque eles não são maneiras
‫completamente certas ou completamente erradas de modelar nossos dados.
‫Não existem regras rígidas; são apenas diretrizes que você pode
‫seguir para encontrar a maneira
‫provavelmente mais correta de estruturar seus dados.
‫Mas, novamente, é difícil estar realmente errado.
‫OK?
‫Agora, digamos que optamos por normalizar nossos conjuntos
‫de dados.
‫Em outras palavras, para fazer referência aos dados.
‫Depois disso, ainda temos que
‫escolher entre três tipos diferentes de referência.
‫Referência de criança, referência de pai
‫e referência bidirecional.
‫Portanto, o primeiro tipo é a referência à criança.
‫Qual é o tipo de referência que eu realmente mostrei antes.
‫OK?
‫E não vamos pegar o exemplo de registro de
‫erros que mencionei anteriormente. Onde poderíamos
‫potencialmente ter milhões de documentos bloqueados.
‫Portanto, na referência de crianças; basicamente mantemos referências aos
‫documentos-filho relacionados em um documento-pai.
‫E geralmente são armazenados em uma matriz.
‫Então, você vê que cada log tem um
‫ID e, no documento do aplicativo, há aquele array com
‫todos esses IDs. Direito?
‫No entanto, o problema aqui é que
‫essa matriz de IDs pode se tornar muito grande se houver muitos filhos.
‫E este é um anti-padrão no MongoDB.
‫Portanto, algo que devemos evitar a todo custo.
‫Além disso, a referência a crianças
‫faz com que pais e filhos estejam intimamente ligados.
‫O que nem sempre é ideal. Mas é exatamente por
‫isso que temos referências aos pais.
‫Portanto, na referência do pai; na verdade,
‫funciona ao contrário.
‫Portanto, aqui em cada documento filho, mantemos uma
‫referência ao elemento pai.
‫Portanto, o nome pai faz referência.
‫Neste exemplo, o ID do aplicativo é 23 e, portanto,
‫em cada log há o campo do aplicativo
‫com o ID 23 nele.
‫Para que a criança sempre conheça seu pai.
‫E então, neste caso, o pai realmente não sabe nada
‫sobre os filhos.
‫Não quem eles são e não quantos são.
‫Então, eles são muito mais isolados e autônomos.
‫Nisso, às vezes pode ser benéfico.
‫Então, qual desses dois tipos é realmente melhor para
‫esse relacionamento de dados.
‫E lembre-se de como eu disse que pode
‫haver milhões de registros e, portanto, vamos supor que haja
‫dois milhões de documentos registrados.
‫Em um caso de referência de criança, isso significaria que há
‫dois milhões de referências
‫de ID no documento do aplicativo.
‫Direito? Agora lembre-se também de como eu
‫disse que há um limite de 16 megabytes para documentos.
‫Portanto, se continuarmos adicionando e adicionando esses IDs filhos à
‫matriz do pai; então, atingiríamos rapidamente
‫o limite de 16 megabytes que cada
‫documento Bson pode conter.
‫Simplesmente porque essa matriz vai crescer muito.
‫Então isso realmente não vai funcionar.
‫É isso?
‫Por outro lado, com o pai
‫referindo-se a esse problema não vai acontecer.
‫Teremos simplesmente dois milhões de documentos
‫bloqueados como antes, mas cada um deles contém a ID de seu pai.
‫Mas não há matriz que
‫cresça indefinidamente e, portanto, a referência
‫do pai seria a melhor solução aqui.
‫Portanto, a conclusão de tudo isso é que,
‫em geral, a referência à criança é mais
‫bem usada para alguns relacionamentos. Onde sabemos de antemão
‫que a variedade de documentos filhos não aumentará tanto.
‫Por outro lado, a referência aos pais é melhor usada
‫para relacionamentos de um para muitos e de um para uma tonelada
‫como este. OK?
‫Portanto, sempre tenha em mente que um dos
‫princípios mais importantes da modelagem de dados
‫MongoDB é que o array nunca deve crescer indefinidamente.
‫Para nunca ultrapassar esse limite de 16 megabytes.
‫Também não queremos enviar aos nossos usuários um array
‫com milhares de IDs cada vez que eles solicitarem
‫um conjunto de dados pai. OK?
‫Então, essa lógica fez sentido para você?
‫Em seguida, vamos passar para o terceiro tipo de
‫referência, que é a referência bidirecional.
‫E desta vez com o exemplo do filme
‫e ator que mostrei quando falamos sobre
‫muitos para muitos relacionamentos. Lembre-se disso?
‫Então, novamente, cada filme tem muitos atores e
‫cada ator atua em muitos filmes.
‫E esse é um relacionamento típico de muitos para muitos.
‫E geralmente usamos essa referência bidirecional para
‫projetar muitos relacionamentos. E funciona
‫assim; em cada filme, manteremos referências a todos os
‫atores que protagonizam aquele filme. É um pouco como na referência infantil.
‫No entanto, e ao mesmo tempo, em cada ator
‫também mantemos referências a todos os filmes
‫em que o ator atuou.
‫Assim, filmes e atores estão conectados em ambas as direções.
‫Portanto, o nome referenciamento bidirecional.
‫E isso torna muito
‫fácil pesquisar filmes e atores de forma totalmente independente.
‫Ao mesmo tempo que facilita a localização dos
‫atores associados a cada filme e dos filmes associados
‫a cada ator.
‫(respire fundo)
‫Esta foi uma palestra bastante longa, de fato.
‫Com muitos novos conceitos, princípios e
‫diretrizes para lembrar.
‫Então, para ajudá-lo com isso; aqui está um breve
‫resumo e algumas diretrizes mais gerais que você
‫pode consultar quando precisar.
‫Portanto, o princípio mais importante é: estruturar seus dados
‫para corresponder às formas como seu aplicativo consulta e
‫atualiza os dados.
‫Ou em outras palavras: identifique as perguntas que surgem dos casos de
‫uso do seu aplicativo primeiro e, em
‫seguida, modele seus dados para que as perguntas possam
‫ser respondidas da maneira mais eficiente.
‫Por exemplo; quando preciso consultar filmes e atores sempre
‫juntos ou há cenários em que só consulto
‫filmes ou apenas atores.
‫É nesse tipo de pergunta que o
‫seu modelo de dados será baseado.
‫Em geral, sempre dê preferência à incorporação, a menos que haja um
‫bom motivo para não incorporar.
‫Especialmente em um para alguns e um para muitos relacionamentos.
‫Em seguida, um relacionamento de um para uma tonelada ou de muitos para muitos
‫é geralmente um bom motivo para fazer referência em vez de incorporar.
‫Além disso, favorece a referência quando os dados são atualizados
‫muito e se você precisa acessar frequentemente um conjunto de dados por conta própria.
‫Use a incorporação quando os dados são mais lidos, mas raramente atualizados, e quando
‫dois conjuntos de dados pertencem intrinsecamente um ao outro.
‫Não permita que os arrays cresçam indefinidamente.
‫Portanto, se você deseja normalizar; use a referência de
‫filho para um para muitos relacionamentos e a referência de pai
‫para um para muitos relacionamentos.
‫E, finalmente, use a referência bidirecional para
‫muitos para muitos relacionamentos.
‫Tudo bem?
‫E isso resume tudo.
‫Na verdade, eu recomendo que você assista a
‫este vídeo duas vezes, se puder, apenas por causa
‫da importância deste material. Tudo bem?
‫Enfim, até o próximo vídeo.