‫Jonas: Quindi nell'ultima lezione
‫abbiamo appreso una teoria sulla modellazione dei dati.
‫E quindi, ora usiamo quella teoria
‫per progettare effettivamente il modello di
‫dati della nostra applicazione Natours.
‫E questa è per me e per molti altri
‫sviluppatori in realtà la parte più difficile della creazione di un'app.
‫E, quindi, spero che questa applicazione ti serva
‫da buon esempio e ti dia le conoscenze
‫per progettare in seguito i tuoi modelli di dati,
‫praticamente completamente da solo.
‫Quindi facciamolo ora.
‫E iniziamo con tutti i set
‫di dati di cui abbiamo effettivamente bisogno nella nostra applicazione.
‫Quindi iniziamo con i tour,
‫e questo è ovviamente il più ovvio.
‫E abbiamo già implementato questo.
‫Poi abbiamo anche bisogno di alcuni utenti.
‫E, ancora, abbiamo già una raccolta di utenti nel
‫nostro database.
‫E, quindi, fondamentalmente tour e utenti
‫sono due set di dati completamente separati.
‫E così li abbiamo normalizzati.
‫E ovviamente non verranno incorporati.
‫Successivamente, avremo anche recensioni e
‫avremo anche posizioni.
‫Va bene?
‫Perché la maggior parte dei tour ha in realtà
‫un numero di posizioni diverse.
‫Va bene?
‫E, quindi, questo è ancora un altro set di dati.
‫E infine, avremo anche le prenotazioni.
‫Ma un po' di più sul perché è in un secondo.
‫Ok, quindi, abbiamo tutti questi set di dati.
‫Ora modelliamo effettivamente le relazioni che esistono
‫tra di loro.
‫E inizierò con
‫il rapporto tra utenti e recensioni.
‫E questa relazione è chiaramente una relazione uno-a-molti perché un utente
‫può scrivere più recensioni, ma una recensione
‫può appartenere a un solo utente.
‫E il genitore in questa relazione sono chiaramente gli utenti,
‫e il figlio, le
‫recensioni perché di nuovo è il genitore, quindi gli utenti in questo caso,
‫che possono essere correlati a molte recensioni,
‫ma una recensione può essere correlata a un solo utente.
‫Ad ogni modo, ho scelto di modellare questa relazione
‫usando il riferimento dei genitori.
‫E questo perché un utente può scrivere molte recensioni e
‫anche perché potremmo aver bisogno di interrogare
‫solo le recensioni da solo.
‫Quindi il modello dell'asse dei dati è
‫davvero importante da prendere in considerazione in questa particolare relazione.
‫Ora, riguardo al tipo di riferimento che
‫useremo, è il riferimento
‫del genitore, quindi fondamentalmente la recensione mantiene un riferimento dell'utente.
‫Quindi mantenere un documento d'identità, in pratica.
‫E questo è come
‫già sai perché non vogliamo permettere a una razza di crescere indefinitamente.
‫E questo potrebbe essere
‫il caso se un utente scrive tonnellate e tonnellate (ride) di recensioni.
‫Va bene?
‫Inoltre, è bello che la recensione sappia chi
‫l'ha effettivamente scritta.
‫Va bene?
‫E quindi, avere l'ID utente proprio sulla recensione
‫ci consentirà anche di farlo.
‫Va bene.
‫Successivamente, diamo
‫un'occhiata alla relazione tra tour e recensioni.
‫E questo è in realtà molto simile.
‫Quindi, ancora una volta, è una relazione uno a
‫molti, in cui un tour può avere
‫più recensioni ma una recensione può riguardare solo un tour.
‫Destra?
‫Quindi è così che ha senso.
‫E, quindi, lo modelleremo esattamente allo stesso
‫modo della relazione utente-recensioni.
‫Quindi, ancora una volta, il riferimento
‫del genitore, in modo che alla fine le
‫recensioni finiscano con un ID tour e un ID utente.
‫E così, una volta che interroghiamo le recensioni,
‫lo sappiamo sempre esattamente.
‫Ottimo, quindi parliamo ora della relazione
‫tra tour e location.
‫Quindi, come ho
‫detto prima, ogni tour avrà un paio di luoghi.
‫Quindi, ad esempio, il camper del parco si fermerà praticamente
‫in tre o quattro parchi nazionali.
‫E, quindi, ognuno di questi parchi
‫nazionali sarà un luogo.
‫Destra?
‫E, quindi, ogni tour avrà fondamentalmente alcune località.
‫Ora, seguendo quell'esempio, uno di questi parchi nazionali
‫potrebbe anche far parte di uno degli altri tour.
‫E, quindi, fondamentalmente questa relazione qui
‫è una relazione da pochi a pochi.
‫E abbiamo chiamato questa relazione molti a molti
‫prima, ma possiamo ancora chiamarli pochi a pochi
‫o una tonnellata a una tonnellata.
‫E, quindi, li ho
‫chiamati pochi a pochi perché ogni tour avrà solo tre, quattro
‫location ma non proprio come 100.
‫Va bene?
‫E, ancora, ciascuna delle location può anche far parte
‫di un altro tour.
‫Ora, questo potrebbe essere un buon esempio per
‫implementare effettivamente il riferimento bidirezionale, quindi fondamentalmente normalizzando le posizioni nel
‫proprio set di dati.
‫Destra?
‫Ma invece denormalizzerò le location
‫per inserirle nei tour.
‫E questo è in realtà per molteplici ragioni.
‫Primo, perché ci sono solo così poche località.
‫Inoltre, non accederemo davvero ai luoghi
‫da soli.
‫E, infine, queste location sono intrinsecamente legate
‫ai tour perché davvero senza location non
‫potrebbero esserci tour.
‫Destra?
‫Quindi questi set di dati sono strettamente collegati.
‫E così, ho scelto di incorporare i luoghi nei tour e
‫di non creare un'altra raccolta per questi.
‫Destra?
‫Quindi avremo una raccolta per i tour, una per gli utenti
‫e poco dopo creeremo anche una nuova raccolta
‫per le recensioni.
‫Va bene?
‫Ma per le località, ancora una volta, perché queste saranno incorporate
‫nei tour.
‫Ok, e poi c'è anche una relazione tra
‫i tour e gli utenti.
‫E questo perché avremo guide
‫turistiche nei tour, e queste guide turistiche saranno effettivamente utenti.
‫Quindi ricordi come abbiamo effettivamente dato agli utenti un ruolo
‫nel nostro schema Mongoose?
‫E le possibilità contenevano la guida e
‫la guida principale, ricordi?
‫E, quindi, ci sarà
‫una relazione tra questi tipi di utenti e i tour.
‫Ora, questa relazione è di nuovo una relazione da pochi a
‫pochi perché un tour può avere solo pochi utenti,
‫quindi poche guide turistiche, ma allo
‫stesso tempo ogni guida turistica può anche guidare alcuni tour.
‫Va bene?
‫E quindi, di nuovo, c'è una relazione molti a molti qui,
‫che ho semplicemente chiamato pochi a pochi.
‫Ora, per modellare effettivamente questa relazione, potremmo
‫farlo in due modi.
‫Potremmo usare il riferimento o l'incorporamento.
‫E in realtà ti mostrerò come
‫implementare sia l'incorporamento dei riferimenti figlio utilizzando Mongoose
‫in questa sezione.
‫Va bene?
‫E l'argomento per l'inclusione è che in questo caso
‫potremmo avere tutte le informazioni su ciascun tour che
‫contengono le informazioni sulle guide
‫turistiche direttamente su ogni documento del tour.
‫Ma d'altra parte, ciò creerebbe
‫quindi alcune informazioni extra nel database
‫perché avremo ancora bisogno di avere gli
‫utenti come una raccolta
‫separata semplicemente perché abbiamo bisogno di accedervi tutto il tempo
‫per l'autenticazione e l'autorizzazione dell'utente e tutto
‫il resto.
‫Quindi, di solito, gli utenti sono sempre un'entità a sé stante
‫in ogni database.
‫Va bene?
‫Ma potremmo ancora incorporare alcuni utenti nei tour.
‫Quindi, in pratica, quando l'utente è una
‫guida turistica per un tour specifico, potremmo copiare tutti questi
‫dati nel documento del tour.
‫Va bene?
‫Ma dovremmo anche aggiornare l'utente durante il tour
‫ogni volta che l'utente sottostante cambia.
‫Quindi diciamo che il ruolo di un utente
‫cambia da guida a guida principale.
‫E in tal caso, dovremmo quindi andare al
‫tour e aggiornare anche le informazioni sul ruolo
‫proprio lì sui dati incorporati.
‫Va bene?
‫E, quindi, non è l'ideale, quindi
‫in realtà implementeremo anche il riferimento ai bambini.
‫E quindi, con ciò,
‫possiamo ancora mantenere fondamentalmente le informazioni
‫sulle guide turistiche sugli utenti, ma semplicemente in una
‫forma referenziata, quindi sostanzialmente mantenendo gli
‫ID lì, che poi indicheranno gli utenti.
‫Va bene?
‫E ovviamente potremmo anche usare il riferimento
‫bidirezionale, quindi anche mantenendo un ID del tour direttamente sull'utente.
‫Ma penso che sia
‫un po' troppo per questo tipo di piccolo
‫esempio perché non tutti gli utenti avranno effettivamente bisogno di un ID del
‫tour perché non tutti gli utenti sono guide turistiche.
‫E, quindi, questa relazione qui è un po' difficile da modellare,
‫penso, ma credo che alla
‫fine il riferimento ai bambini sarà il modo migliore per andare.
‫Va bene?
‫Tuttavia, ti mostrerò anche l'incorporamento
‫perché penso che sia importante anche imparare.
‫Va bene?
‫Poi abbiamo le nostre prenotazioni.
‫E fondamentalmente verrà creata una nuova
‫prenotazione ogni volta che un utente acquista un tour.
‫Quindi questa è ancora una sorta
‫di relazione tra utenti e
‫tour perché di nuovo è un utente che comprerà un tour.
‫Ma vogliamo anche memorizzare
‫alcuni dati su quella relazione stessa,
‫quindi in questo caso sull'acquisto stesso nel nostro database.
‫Ad esempio, il prezzo o la
‫data in cui è avvenuto l'acquisto o qualcosa del genere.
‫E quindi, in casi
‫come questo, è una buona idea creare un set di dati
‫extra, che in questo caso sono le prenotazioni.
‫Va bene?
‫E quindi, ovviamente, ci sarà
‫una relazione tra tour e prenotazioni e anche utenti e prenotazioni.
‫E, ancora, perché fondamentalmente la prenotazione collega i tour
‫con gli utenti ma con un passaggio intermedio.
‫Quindi un tour può avere molte prenotazioni,
‫ma una prenotazione può appartenere a un solo tour.
‫E la stessa cosa con gli utenti.
‫Quindi un utente può prenotare più
‫tour, ma una prenotazione può appartenere solo a uno degli utenti.
‫E quindi, ovviamente, abbiamo una relazione uno a molti
‫in entrambi i casi, e anche in entrambi i
‫casi, useremo il riferimento dei genitori.
‫E, quindi, ciò significa che su ogni
‫prenotazione conserveremo un ID sia del tour che è stato acquistato sia
‫anche dell'utente che ha effettivamente acquistato il tour.
‫Va bene?
‫E quindi, in questo caso, lo
‫sto facendo in questo modo perché fondamentalmente non voglio inquinare i
‫dati del tour con informazioni su chi ha effettivamente acquistato il tour.
‫Destra?
‫Non sarebbe davvero rilevante per i dati del tour stesso.
‫E la stessa cosa con gli utenti.
‫Quindi non vogliamo nemmeno inquinare l'oggetto degli utenti con
‫tutte le prenotazioni che hanno fatto.
‫Va bene?
‫E così, invece,
‫creeremo di nuovo un oggetto intermedio o un
‫set di dati intermedio che starà tra
‫gli utenti e i tour ogni volta che creano un nuovo acquisto.
‫Destra?
‫Ha senso?
‫E questo è effettivamente tutto per il nostro modello di dati.
‫E ovviamente, ora sembra un po' astratto, ma una volta
‫che inizieremo a implementarlo,
‫sarà molto utile
‫avere tutte le nostre idee organizzate in qualcosa del genere.
‫Quindi, ogni volta che questo modello di dati
‫che implementeremo in questa sezione ti crea un po' di
‫confusione, fai semplicemente riferimento a questa diapositiva.
‫Oppure puoi anche stamparlo se questo
‫ti rende più facile.
‫Quindi questo è il nostro modello di dati in teoria.
‫E ora durante il resto del corso,
‫ti fornirò gli strumenti per modellare effettivamente i dati
‫utilizzando la libreria Mongoose.