‫Narratore: Uno dei passaggi più
‫importanti nella creazione di app ad alta intensità di dati
‫è modellare effettivamente tutti questi dati in MongoDB.
‫Ed è di questo che parleremo in questa lezione.
‫Quindi è davvero fondamentale seguirlo
‫anche all'inizio è molto da accettare. Va bene.
‫Comunque, ora iniziamo.
‫Ora, la modellazione dei dati è probabilmente un concetto molto nuovo per te.
‫Quindi, prima di
‫iniziare; chiariamo di cosa parleremo in realtà.
‫Quindi, la modellazione dei dati è il processo di prendere dati
‫non strutturati generati da uno scenario del mondo reale
‫e quindi strutturarli in un modello di dati logico
‫in un database.
‫E lo facciamo secondo una serie
‫di criteri che impareremo in questo video.
‫Per esempio; diciamo che vogliamo progettare un modello
‫di dati del negozio online.
‫Inizialmente ci saranno una tonnellata di dati non strutturati di cui
‫sappiamo di aver bisogno.
‫Destra.
‫Cose come prodotti, categorie,
‫ordini dei clienti, carrelli della spesa, fornitori.
‫E così via e così via.
‫Il nostro obiettivo con la modellazione dei dati è quindi
‫strutturare questi dati in modo logico.
‫Riflettendo le relazioni del mondo reale che
‫esistono tra alcuni di questi set di dati.
‫Un po' come puoi vedere in questo esempio.
‫E questa è ovviamente solo una specie di situazione immaginaria,
‫ma rende l'idea.
‫Destra.
‫Ora, molti sviluppatori di backend affermano che la modellazione dei dati
‫è dove dobbiamo pensare di più.
‫Questa è la parte più impegnativa della
‫creazione di un'intera applicazione.
‫Perché in realtà non è sempre semplice.
‫E a volte semplicemente non ci sono risposte giuste.
‫Quindi non solo un unico modo corretto di strutturare i dati.
‫Ma comunque farò del mio meglio per definire il processo
‫in questo video.
‫E per questo faremo quattro passi.
‫Quindi nel primo passaggio; abbiamo imparato come identificare diversi
‫tipi di relazioni tra i dati.
‫Allora
‫capiremo la differenza tra
‫referenziazione o normalizzazione e incorporamento o denormalizzazione.
‫Nel passaggio successivo e
‫più importante; Ti mostrerò la mia struttura per
‫decidere se dobbiamo incorporare documenti
‫o fare riferimento ad altri documenti
‫in base a un paio di fattori diversi.
‫Inoltre, dobbiamo parlare rapidamente di
‫diversi tipi di referenziazione.
‫Perché questo è importante se questo è il tipo di
‫design che scegliamo per i nostri dati.
‫Quindi questa sarà in effetti una lezione abbastanza teorica.
‫Ma anche assolutamente essenziale per i tuoi progressi
‫come sviluppatore back-end.
‫Perché il modo in cui progettiamo i dati e il modo in
‫cui modelliamo i nostri dati può creare o distruggere l'intera applicazione.
‫E ci saranno molti esempi lungo la strada per
‫rendere questo processo più semplice.
‫Va bene.
‫E la prima cosa di
‫cui parleremo sono i diversi tipi di
‫relazioni che possono esistere tra i dati.
‫Quindi ci sono tre grandi tipi di relazioni.
‫Uno a uno, uno a molti e molti a molti.
‫E userò un'applicazione per
‫film come esempio in questa diapositiva.
‫Va bene?
‫Quindi, prima una relazione uno a uno
‫tra i dati è
‫fondamentalmente quando un campo può avere un solo valore.
‫Quindi nel nostro esempio di applicazione per film; un film ha sempre
‫e solo un nome.
‫E quindi questo è un
‫semplice esempio di relazione uno a uno.
‫Ma queste relazioni non sono poi così importanti in
‫termini di modellazione dei dati.
‫Ora le relazioni più
‫importanti sono le relazioni uno a molti.
‫E sono così importanti che in MongoDB
‫distinguiamo effettivamente tra tre tipi di relazioni
‫da uno a molti.
‫Uno a pochi, uno a molti e uno a una tonnellata o a un milione
‫o qualcosa del genere. Quindi la differenza qui si
‫basa sulla quantità relativa dei molti. Va bene.
‫Quindi un esempio per una relazione uno a
‫pochi è che un film può vincere molti premi, ma in realtà solo pochi.
‫Quindi il film non vincerà mille premi, ma
‫può vincerne alcuni.
‫E quindi questo è un tipico rapporto da uno a pochi.
‫Quindi vedi che in generale una relazione uno a
‫molti significa che un documento può essere correlato a molti altri documenti.
‫Ora questo potrebbe sembrare un po' astratto senza i dati JSON, ma in
‫realtà è questo lo scopo qui.
‫Voglio solo mostrarti una panoramica
‫concettuale di questi diversi tipi di relazioni.
‫Ad ogni modo, qualsiasi relazione uno a
‫molti un documento può riguardare centinaia o migliaia di
‫altri documenti.
‫Per esempio; un film può avere migliaia di
‫recensioni nella nostra applicazione.
‫E quindi questo non è proprio un rapporto uno a pochi,
‫ma uno a molti. Va bene?
‫E infine abbiamo il rapporto uno a ton.
‫Immagina di voler implementare alcune funzionalità di registrazione
‫nella nostra app. Quindi, in pratica, per sapere
‫esattamente cosa sta succedendo sul nostro server.
‫Questi registri possono quindi crescere facilmente fino a milioni di documenti.
‫E quindi questo è un esempio
‫molto tipico di una relazione da uno a tonnellate.
‫E la differenza tra molti e una tonnellata
‫è ovviamente un po' confusa, ma pensa solo che se qualcosa
‫può crescere quasi all'infinito, allora è sicuramente una
‫relazione uno a una tonnellata.
‫Quindi ancora una volta le relazioni uno a
‫molti sono le più importanti da conoscere.
‫A proposito; nei database
‫relazionali c'è solo uno a molti
‫senza quantificare quanti siano effettivamente.
‫Nei database MongoDB però
‫è una differenza estremamente importante.
‫Perché è uno dei fattori che useremo
‫per decidere se dobbiamo denormalizzare o
‫normalizzare i dati, come imparerai un po' più tardi.
‫Ad ogni modo, il tipo di relazione minore è il molti a
‫molti in cui un film può avere molti attori.
‫Ma allo stesso tempo un attore può recitare in molti film.
‫E quindi qui la relazione va sostanzialmente in
‫entrambe le direzioni.
‫Dove prima negli altri tipi era
‫solo in una direzione.
‫Ad esempio, un film può avere molte recensioni, ma una
‫specifica è solo per quel film. Destra.
‫E lo stesso vale per i premi.
‫Quindi un premio specifico come per il miglior
‫attore va a un solo film, non a più film.
‫Ma con i film e gli attori è davvero diverso.
‫Quindi ancora una volta un film ha molti attori,
‫ma un attore interpreta molti film
‫e quindi è una relazione molti a molti.
‫Va bene.
‫Quindi tieni tutto questo a mente mentre andiamo avanti
‫in questa lezione.
‫E probabilmente l'aspetto più importante che dobbiamo imparare
‫sui database MongoDB è fare riferimento e
‫incorporare due set di dati.
‫E in realtà ne abbiamo
‫già parlato un po' prima, ma esaminiamolo
‫qui e approfondiamo anche un po'.
‫Quindi, ogni volta che abbiamo due
‫set di dati correlati, possiamo rappresentare quei dati correlati in
‫una forma di riferimento o normalizzata o in una forma incorporata o denormalizzata.
‫E continuo a usare i due termini correlati insieme
‫come fare riferimento e normalizzare perché
‫li vedrai entrambi usati e
‫quindi è importante che tu li conosca tutti.
‫Ad ogni modo, nel modulo di riferimento manteniamo due set di
‫dati correlati e tutti i documenti separati.
‫Quindi di nuovo tutti i dati sono ben separati,
‫il che è esattamente ciò che significa normalizzato.
‫Quindi, continuando, l'esempio del database del film di prima
‫avremmo un documento del film e un documento
‫dell'attore per ogni attore. Ora come faremmo quindi a stabilire
‫la connessione tra il film e gli attori in modo che in seguito nella
‫nostra app possiamo mostrare quali attori hanno recitato in un particolare film.
‫Perché se sono tutti documenti completamente diversi il film non
‫ha modo di conoscere gli attori. Destra.
‫Bene, è qui che entrano in gioco gli ID.
‫Quindi usiamo gli ID attore per creare riferimenti sul
‫documento del film.
‫Connettere efficacemente i film con gli attori.
‫Quindi vedi che in un documento di film abbiamo un array in
‫cui abbiamo archiviato gli ID di tutti gli
‫attori in modo che quando richiediamo dati su un certo film possiamo
‫facilmente identificare i suoi attori. Ha senso?
‫Ora questo tipo di riferimento è chiamato riferimento figlio perché è il
‫genitore in questo caso il film che fa
‫riferimento ai suoi figli. In questo caso gli attori.
‫Quindi stiamo davvero creando una sorta di gerarchia qui. Destra.
‫Ora c'è anche la referenza dei genitori e
‫ne parleremo un po' più tardi.
‫E tra l'altro nei database relazionali; tutti i dati sono
‫sempre rappresentati in forma normalizzata come questa.
‫Ma in un database senza sequel come
‫MongoDB possiamo denormalizzare i dati in una forma
‫denormalizzata semplicemente incorporando il
‫documento correlato direttamente nel documento principale.
‫Quindi ora abbiamo tutti i dati rilevanti
‫sugli attori direttamente all'interno di un documento principale del film
‫senza la necessità di documenti, raccolte e ID separati.
‫Quindi, ancora una volta, se scegliamo di denormalizzare o incorporare i nostri
‫dati, avremo un documento principale contenente tutti i dati principali e
‫i relativi dati. Va bene.
‫E il risultato è che la nostra applicazione
‫avrà bisogno di meno query al database.
‫Perché possiamo ottenere
‫tutti i dati su film e attori
‫contemporaneamente, il che ovviamente aumenterà le nostre prestazioni.
‫Ora il lato negativo qui è
‫ovviamente che non possiamo davvero interrogare i dati incorporati da soli.
‫Quindi, se questo è un requisito per l'applicazione,
‫dovresti scegliere un design normalizzato e poiché
‫stiamo parlando di pro e contro
‫della forma denormalizzata; facciamo lo stesso
‫con il design normalizzato.
‫E fondamentalmente è l'opposto di quello di
‫cui abbiamo appena parlato.
‫Quindi c'è un miglioramento delle prestazioni
‫quando spesso abbiamo bisogno di interrogare i dati correlati da soli
‫perché possiamo semplicemente interrogare i dati di cui abbiamo
‫bisogno e non sempre film e attori insieme.
‫Ma d'altra parte; quando abbiamo bisogno di interrogare effettivamente
‫film e attori insieme, allora
‫avremo bisogno di molte query al database.
‫Quindi prima la query per il film e poi da lì
‫avremo anche bisogno di una query per l'attore
‫e questo ovviamente funziona per le prestazioni.
‫Quindi, quando si progetta il database; questo è il tipo di cose che
‫devi tenere a mente. Va bene.
‫E ora solo come nota a margine; potremmo ovviamente iniziare il nostro
‫processo di pensiero con dati denormalizzati
‫e poi giungere alla conclusione che è meglio
‫normalizzare effettivamente i dati.
‫Quindi, quando si pensa al nostro modello di dati, questo modo
‫di organizzare i dati funziona ovviamente in entrambi i modi.
‫Ora, come decidiamo effettivamente se dobbiamo normalizzare
‫o denormalizzare i dati?
‫Bene, questo è esattamente ciò che impareremo dopo.
‫Quindi, quando abbiamo due set di dati correlati; dobbiamo decidere
‫se incorporeremo i set di dati o se li terremo
‫separati e li
‫faremo riferimento da un set di dati all'altro.
‫E ho in qualche modo sviluppato
‫questo quadro decisionale che ti mostrerò dove usiamo tre criteri
‫per prendere quella decisione.
‫Per prima cosa esaminiamo il tipo di relazioni
‫esistenti tra i set di dati.
‫In secondo luogo, cerchiamo di determinare il modello di
‫accesso ai dati del set di dati che vogliamo incorporare o fare riferimento.
‫E questo significa solo analizzare la frequenza con cui i dati vengono letti
‫e scritti in quel set di dati.
‫Quindi esaminiamo anche qualcosa che chiamo vicinanza dei dati.
‫E la vicinanza dei dati è un termine che in realtà ho
‫appena inventato, ma ciò che significa è quanto i dati sono realmente
‫correlati e come vogliamo interrogare i dati dal database.
‫E questo avrà più
‫senso quando ne parleremo tra un momento.
‫Ora per prendere effettivamente la decisione; dobbiamo combinare
‫tutti e tre questi
‫criteri e non usarne solo uno isolatamente.
‫Quindi, per esempio; solo perché il criterio numero uno dice
‫di incorporare non significa che non abbiamo bisogno di
‫guardare gli altri due criteri.
‫Va bene e iniziamo con il tipo di relazione.
‫Quindi, di solito, quando abbiamo una relazione da uno a pochi,
‫incorporeremo sempre il set di dati correlato nel
‫set di dati principale proprio come abbiamo
‫appreso nell'ultima diapositiva. Destra.
‫Ora in una relazione uno a molti; le cose
‫sono un po' più confuse, quindi va bene incorporare o fare riferimento.
‫In tal caso dovremo decidere secondo
‫gli altri due criteri.
‫Ora, d'altra parte, su una relazione uno
‫a una tonnellata o molti a molti di solito facciamo sempre
‫riferimento ai dati. Questo perché se lo incorporassimo
‫effettivamente in questo caso potremmo creare rapidamente un documento troppo grande.
‫Anche potenzialmente superando il massimo di 16 megabyte.
‫E quindi la soluzione è ovviamente fare riferimento
‫o normalizzare i dati. E come rapido esempio;
‫diciamo che nel nostro esempio di
‫database di film abbiamo circa 100 immagini associate a ciascun film.
‫Quindi potremmo dire che è una relazione uno a
‫molti, ma incorporeremo il set di dati o dovremmo piuttosto fare
‫riferimento a loro qui. Beh, non lo sappiamo davvero.
‫Quindi diamo un'occhiata agli altri due criteri.
‫Quindi il secondo riguarda i modelli di accesso ai dati in
‫cui è solo una
‫descrizione fantasiosa per valutare se un
‫determinato set di dati viene principalmente scritto o letto principalmente.
‫Quindi, se il set di dati su cui stiamo decidendo è per lo
‫più letto e i dati non
‫vengono aggiornati molto, probabilmente dovremmo incorporare quel set di dati.
‫Quindi un alto rapporto di lettura/scrittura significa semplicemente che
‫c'è molta più lettura che scrittura.
‫E ancora, un set di dati del genere è un buon candidato
‫per l'incorporamento.
‫La ragione di ciò è che incorporando abbiamo solo bisogno
‫di un viaggio nel database per query.
‫Mentre per la referenziazione occorrono due viaggi. Destra.
‫Quindi, se incorporiamo dati che vengono letti molto;
‫in ogni query salviamo un
‫viaggio nel database rendendo l'intero processo molto più performante.
‫Quindi penso che il nostro esempio di immagine del
‫film sarebbe effettivamente un buon candidato per l'incorporamento.
‫Perché una volta che le 100 immagini vengono
‫salvate nel database non vengono più
‫aggiornate realmente perché non c'è davvero nulla da
‫aggiornare su un'immagine. Giusto, quindi si
‫tratta solo di leggere e quindi in
‫base a questo criterio incorporeremmo i documenti immagine.
‫Ora, d'altra parte, se i nostri dati vengono
‫aggiornati molto, dovremmo considerare di fare riferimento o normalizzare i dati.
‫Questo perché è più lavoro per il motore del
‫database aggiornare e incorporare un
‫documento rispetto a un semplice documento autonomo.
‫E poiché il nostro obiettivo principale è la prestazione;
‫normalizziamo semplicemente il set di dati.
‫Nel nostro esempio diciamo che ogni film ha molte recensioni
‫e ogni recensione può essere contrassegnata come utile dall'utente.
‫Quindi ogni volta che qualcuno fa clic su questa recensione è stato utile
‫nella nostra applicazione. Dobbiamo
‫aggiornare il documento corrispondente.
‫E questo significa che i dati possono cambiare continuamente
‫e quindi questo è un ottimo candidato per la normalizzazione.
‫Ancora una volta perché non vogliamo interrogare continuamente
‫i film se tutto ciò che vogliamo davvero aggiornare sono
‫le recensioni contrassegnandole come utili.
‫Ok, ha senso?
‫E infine l'ultimo criterio che chiamo vicinanza dei dati; che è
‫proprio come una misura per quanto i
‫dati sono correlati. Quindi, se i
‫due set di dati appartengono davvero intrinsecamente insieme,
‫allora dovrebbero probabilmente essere incorporati l'uno nell'altro.
‫Nel nostro esempio; tutti gli utenti possono avere molti indirizzi e-mail
‫sul proprio account e poiché sono così intrinsecamente
‫connessi all'utente, non c'è dubbio che le e-mail
‫dovrebbero essere incorporate nel documento.
‫Ora, se abbiamo spesso bisogno di interrogare entrambi i set di dati
‫da soli, questo è un ottimo motivo
‫per normalizzare i dati in due set di dati separati.
‫Anche se sono strettamente imparentati.
‫Quindi immagina che nella nostra app
‫abbiamo un quiz in cui gli utenti devono identificare un film in base alle immagini.
‫Ciò significa che interrogheremo molte immagini
‫da sole.
‫Quindi senza necessariamente chiedere i film stessi.
‫E quindi se applichiamo questo terzo criterio;
‫arriviamo alla conclusione che dovremmo effettivamente normalizzare il set
‫di dati dell'immagine. Va bene.
‫Perché ancora una volta se implementiamo questa funzionalità di quiz;
‫le immagini verranno sempre interrogate da sole.
‫Quindi, tutto ciò mostra che dovremmo davvero guardare tutti
‫e tre i criteri insieme
‫piuttosto che uno solo di essi isolatamente.
‫Perché ciò potrebbe portare a decisioni meno ottimali.
‫E dico meno ottimale invece di sbagliato
‫perché non sono modi completamente giusti
‫o completamente sbagliati di modellare i nostri dati.
‫Non ci sono regole rigide; queste sono proprio delle linee guida che
‫puoi seguire per trovare il modo
‫probabilmente più corretto di strutturare i tuoi dati.
‫Ma ancora una volta, è difficile sbagliarsi davvero.
‫Va bene?
‫Ora, diciamo che abbiamo scelto di normalizzare i nostri
‫set di dati.
‫Quindi, in altre parole, per fare riferimento ai dati.
‫Dopodiché, dobbiamo ancora scegliere
‫tra tre diversi tipi di referenziazione.
‫Referenziazione del bambino, referenziazione del genitore
‫e referenziazione bidirezionale.
‫Quindi il primo tipo è il riferimento ai bambini.
‫Qual è il tipo di riferimento che ti ho mostrato prima.
‫Va bene?
‫E non prendiamo l'esempio di registrazione degli errori che
‫ho menzionato prima. Dove potremmo
‫potenzialmente avere milioni di documenti bloccati.
‫Quindi nel referenziamento dei bambini; fondamentalmente manteniamo i riferimenti ai
‫relativi documenti figlio in un documento padre.
‫E di solito sono memorizzati in un array.
‫Quindi vedi che ogni registro ha un ID
‫e quindi nel documento dell'app c'è quell'array con tutti
‫questi ID. Destra?
‫Tuttavia, il problema qui è che questa
‫serie di ID può diventare molto grande se ci sono molti bambini.
‫E questo è un anti-pattern in MongoDB.
‫Quindi qualcosa che dovremmo evitare a tutti i costi.
‫Inoltre, la referenziazione dei bambini
‫fa sì che genitori e figli siano strettamente legati.
‫Il che non è sempre l'ideale. Ma questo è esattamente il
‫motivo per cui abbiamo le referenze dei genitori.
‫Quindi nella referenziazione dei genitori; in realtà
‫funziona al contrario.
‫Quindi qui in ogni documento figlio manteniamo un
‫riferimento all'elemento genitore.
‫Quindi il nome genitore di riferimento.
‫In questo esempio l'ID app è 23 e quindi in
‫ogni registro c'è il campo app con
‫l'ID 23 al suo interno.
‫In modo che il bambino conosca sempre il suo genitore.
‫E quindi in questo caso il genitore in realtà non sa
‫nulla dei figli.
‫Non chi sono e non quanti sono.
‫Quindi, sono molto più isolati e autonomi.
‫In questo, a volte può essere utile.
‫Quindi quale di questi due tipi è effettivamente migliore per
‫questa relazione di dati.
‫E ricorda come ho detto che potrebbero
‫esserci milioni di registri e quindi supponiamo che ci siano
‫due milioni di documenti registrati.
‫In un caso di riferimento figlio, ciò significherebbe che ci
‫sono due milioni di
‫riferimenti ID nel documento dell'app.
‫Destra? Ora ricorda anche come ho detto
‫che c'è un limite di 16 megabyte sui documenti.
‫Quindi, se continuassimo ad aggiungere e aggiungere questi ID figlio
‫nell'array sul genitore; quindi raggiungeremmo abbastanza
‫rapidamente quel limite di 16 megabyte che
‫ogni documento Bson può contenere.
‫Semplicemente perché quell'array crescerà così tanto.
‫Quindi non funzionerà davvero.
‫È?
‫D'altra parte con il riferimento
‫del genitore che il problema non accadrà.
‫Avremo semplicemente due milioni di documenti
‫bloccati proprio come prima, ma ognuno di essi possiede l'ID del suo genitore.
‫Ma non esiste un array
‫che crescerà indefinitamente e quindi il
‫riferimento genitore sarebbe la soluzione migliore qui.
‫Quindi la conclusione di tutto questo è che in
‫generale il riferimento ai bambini è meglio usato per
‫relazioni da uno a pochi. Dove sappiamo in anticipo che
‫la serie di documenti figlio non crescerà così tanto.
‫D'altra parte, il riferimento dei genitori è meglio utilizzato
‫per relazioni uno a molti e uno a una tonnellata
‫come questa. Va bene?
‫Quindi, ancora una volta, tieni sempre presente che uno
‫dei principi più importanti della modellazione dei
‫dati MongoDB è che l'array non dovrebbe mai crescere indefinitamente.
‫Per non infrangere mai quel limite di 16 megabyte.
‫Inoltre, non vogliamo inviare ai nostri utenti un array
‫con migliaia di ID ogni volta che richiedono
‫un set di dati padre. Va bene?
‫Quindi questa logica aveva senso per te?
‫Quindi passiamo al terzo tipo di referenziazione
‫che è la referenziazione bidirezionale.
‫E questa volta con l'esempio del film e dell'attore
‫che ti ho mostrato quando abbiamo parlato
‫di molte a molte relazioni. Ricordati che?
‫Quindi, di nuovo, ogni film ha molti attori
‫e ogni attore recita in molti film.
‫E quindi questa è una tipica relazione molti a molti.
‫E di solito usiamo questo riferimento bidirezionale per progettare
‫relazioni molti a molti. E funziona così;
‫in ogni film manterremo i riferimenti a tutti gli attori
‫che recitano in quel film. Quindi un po' come nei riferimenti ai bambini.
‫Tuttavia e allo stesso tempo in ogni attore
‫conserviamo anche riferimenti a tutti i film
‫in cui l'attore ha recitato.
‫Quindi film e attori sono collegati in entrambe le direzioni.
‫In quindi il nome bidirezionale di riferimento.
‫E questo rende davvero facile
‫la ricerca di film e attori in modo completamente indipendente.
‫Rendendo anche facile trovare gli attori
‫associati a ciascun film e i film associati
‫a ciascun attore.
‫(respiro profondo)
‫Questa è stata davvero una conferenza piuttosto lunga.
‫Con molti nuovi concetti, principi e
‫linee guida da ricordare.
‫Quindi, per aiutarti in questo; ecco un breve riassunto e
‫alcune linee guida più generali a cui puoi dare
‫un'occhiata quando ne hai bisogno.
‫Quindi il principio più importante è: strutturare i dati in modo
‫che corrispondano ai modi in cui l'applicazione esegue query e
‫aggiorna i dati.
‫O in altre parole: identifica prima le domande che emergono dai casi
‫d'uso della tua applicazione, quindi modella i
‫tuoi dati in modo che le domande possano
‫ottenere risposta nel modo più efficiente.
‫Per esempio; quando ho bisogno di interrogare film e attori
‫sempre insieme o ci sono scenari in cui interrogo solo
‫film o solo attori.
‫Quel tipo di domande è su cosa si
‫baserà il tuo modello di dati.
‫In generale, preferire sempre l'incorporamento, a meno che non vi sia una
‫buona ragione per non farlo.
‫Soprattutto su uno a pochi e uno a molti rapporti.
‫Successivamente, una relazione uno a tonnellata o molti a molti è di
‫solito una buona ragione per fare riferimento invece di incorporare.
‫Inoltre, preferire il riferimento quando i dati vengono aggiornati molto
‫e se è necessario accedere frequentemente a un set di dati da solo.
‫Utilizzare l'incorporamento quando i dati vengono per lo più letti ma aggiornati raramente e
‫quando due set di dati appartengono intrinsecamente insieme.
‫Non consentire agli array di crescere indefinitamente.
‫Pertanto, se vuoi normalizzare; usa il riferimento figlio per
‫le relazioni uno a molti e il riferimento genitore per le
‫relazioni uno a una tonnellata.
‫E infine usa il riferimento bidirezionale per
‫le relazioni molti a molti.
‫Va bene?
‫E questo praticamente riassume.
‫In realtà ti consiglierei di guardare questo
‫video due volte, se puoi, proprio per l'importanza
‫di questo materiale. Va bene?
‫Comunque, ci vediamo al prossimo video.