Lezione 3: Database, Collection e Documenti in MongoDB - La Struttura NoSQL

Questa lezione approfondisce i concetti fondamentali di MongoDB: database, collection e documenti. Scopri la struttura NoSQL, come interagire con i dati e le differenze chiave rispetto ai database relazionali.

Introduzione: Il Mondo di MongoDB e la Struttura NoSQL

Benvenuti alla terza lezione del nostro corso su MongoDB! Dopo aver esplorato le basi e l'installazione, è ora di immergerci nel cuore di MongoDB: la sua struttura dati. Se provenite dal mondo dei database relazionali (RDBMS) come MySQL o PostgreSQL, troverete alcune analogie, ma è fondamentale comprendere le differenze concettuali che rendono MongoDB un database NoSQL così potente e flessibile.

MongoDB è un database orientato ai documenti, il che significa che i dati non sono organizzati in tabelle rigide con righe e colonne predefinite, bensì in "documenti" flessibili in formato BSON (Binary JSON). Questa natura "schema-less" o "schemaless-by-design" è una delle sue caratteristiche distintive e offre un'agilità incredibile nello sviluppo di applicazioni web moderne, dove i requisiti dei dati possono evolvere rapidamente.

Perché questa flessibilità è cruciale nella programmazione web? Immaginate di sviluppare un'applicazione e-commerce. In un database relazionale, dovreste definire tabelle per prodotti, utenti, ordini, categorie, ecc., con schemi ben precisi. Ogni volta che aggiungete un nuovo attributo a un prodotto (es. 'colore' o 'taglia' per alcuni prodotti, ma non per altri), dovreste alterare lo schema della tabella, il che può essere complesso e richiedere tempi di inattività. Con MongoDB, potete semplicemente aggiungere il campo 'colore' o 'taglia' solo ai documenti dei prodotti che ne hanno bisogno, senza influenzare gli altri documenti o richiedere modifiche allo schema globale. Questo si traduce in cicli di sviluppo più rapidi e una maggiore capacità di adattarsi ai cambiamenti.

In questa lezione, esploreremo in dettaglio i tre pilastri su cui si fonda l'organizzazione dei dati in MongoDB: i database, le collection e i documenti. Impareremo come sono correlati, come interagire con essi e quali sono le migliori pratiche per modellarli efficacemente.

Comprendere i Database in MongoDB

In MongoDB, un database è il contenitore di livello superiore per le tue informazioni. È un'entità logica che raggruppa collection correlate. L'analogia più semplice con il mondo relazionale è che un database MongoDB è simile a un database MySQL o PostgreSQL: è un'istanza isolata che contiene un insieme di tabelle (che in MongoDB chiamiamo collection).

Quando si lavora con MongoDB, non è necessario creare esplicitamente un database prima di usarlo. Se provi a scrivere dati in un database che non esiste, MongoDB lo creerà automaticamente per te. Questa è una delle sue comodità, ma richiede anche un minimo di attenzione per evitare di creare database indesiderati a causa di errori di battitura.

Selezione e Visualizzazione dei Database

Per iniziare a lavorare con un database specifico, si utilizza il comando use nella shell di MongoDB. Se il database esiste, la shell si connette ad esso. Se non esiste, lo crea implicitamente e poi vi si connette.

// Seleziona o crea il database 'miaApplicazione'
use miaApplicazione

// Questo comando restituirà il nome del database corrente
db

Per visualizzare tutti i database presenti sull'istanza di MongoDB, si usa il comando show dbs:

// Mostra tutti i database disponibili
show dbs

L'output di show dbs mostrerà il nome del database e la sua dimensione. Noterete spesso alcuni database di sistema come admin, config e local. Questi sono utilizzati da MongoDB per scopi interni e non dovrebbero essere modificati direttamente.

È importante notare che un database vuoto (senza collection) non appare nell'elenco di show dbs. Un database viene visualizzato solo dopo che vi è stata creata almeno una collection e vi sono stati inseriti dei documenti.

Le Collection: Contenitori di Documenti

All'interno di un database MongoDB, i dati sono organizzati in collection. Una collection è l'equivalente concettuale di una tabella in un database relazionale. Tuttavia, c'è una differenza fondamentale: mentre le tabelle relazionali impongono uno schema fisso a tutte le righe, le collection di MongoDB sono schemaless.

Questo significa che i documenti all'interno di una singola collection possono avere strutture diverse. Possono avere campi differenti, tipi di dati differenti e anche strutture annidate completamente diverse. Questa flessibilità è un enorme vantaggio per lo sviluppo agile e per la gestione di dati semi-strutturati o non strutturati.

Creazione e Naming delle Collection

Come per i database, le collection vengono create implicitamente non appena si inserisce il primo documento al loro interno. Non è necessario un comando CREATE TABLE esplicito.

// Seleziona il database 'miaApplicazione'
use miaApplicazione

// Inserisci un documento nella collection 'utenti'. Se 'utenti' non esiste, viene creata.
db.utenti.insertOne({ nome: 'Mario', cognome: 'Rossi', eta: 30 })

Per visualizzare tutte le collection all'interno del database attualmente selezionato, si usa il comando show collections:

// Mostra tutte le collection nel database corrente
show collections

Regole di Naming per le Collection:

  • I nomi delle collection non possono essere stringhe vuote ("").
  • Non possono contenere il carattere nullo ( ).
  • Non possono iniziare con system. (questo è riservato alle collection di sistema).
  • Devono essere convalidate UTF-8.
  • È buona pratica usare nomi significativi e in minuscolo, spesso al plurale (es. prodotti, ordini).

Vantaggi della Flessibilità delle Collection

La natura schemaless delle collection permette di adattarsi rapidamente ai cambiamenti nei requisiti dell'applicazione. Non c'è bisogno di migrazioni di schema complesse quando si aggiungono o si rimuovono campi. Questo accelera lo sviluppo e semplifica la manutenzione. Ad esempio, in una collection prodotti, alcuni documenti potrebbero rappresentare libri con campi come autore e isbn, mentre altri potrebbero essere vestiti con taglia e colore, e tutto ciò può coesistere nella stessa collection senza problemi.

I Documenti: Il Cuore dei Dati in MongoDB

Il documento è l'unità fondamentale di dati in MongoDB. È l'equivalente di una riga in una tabella relazionale, ma con una differenza cruciale: un documento è una struttura dati BSON (Binary JSON) composta da coppie campo-valore. BSON è una rappresentazione binaria serializzata di JSON che include tipi di dati aggiuntivi non presenti in JSON standard, come Date e ObjectID.

Un documento MongoDB è auto-descrittivo e può contenere oggetti annidati e array, permettendo di rappresentare gerarchie di dati complesse in un singolo record. Questo riduce la necessità di join complessi, tipici dei database relazionali, rendendo le query più veloci e semplici per molti scenari di utilizzo web.

Struttura e Tipi di Dati

Ogni documento ha un campo speciale _id, che funge da chiave primaria per il documento all'interno della collection. Se non lo si specifica durante l'inserimento, MongoDB genera automaticamente un ObjectID univoco per esso. L'_id è cruciale per l'identificazione e l'indicizzazione dei documenti.

Ecco un esempio di documento:

{
  "_id": ObjectId("65d2c7f3e1b7c8a9d0e1f2g3"),
  "nome": "Alice",
  "cognome": "Verdi",
  "email": "alice.verdi@esempio.com",
  "indirizzi": [
    {
      "tipo": "casa",
      "via": "Via Roma 10",
      "citta": "Milano",
      "cap": "20100"
    },
    {
      "tipo": "lavoro",
      "via": "Corso Italia 5",
      "citta": "Milano",
      "cap": "20120"
    }
  ],
  "dataRegistrazione": ISODate("2023-01-15T10:30:00Z"),
  "attivo": true,
  "preferenze": {
    "notificheEmail": true,
    "lingua": "it"
  }
}

Questo documento mostra diversi tipi di dati comuni in MongoDB:

  • Stringhe: nome, cognome, email, via, citta, cap, tipo, lingua.
  • Numeri: Nessun esempio diretto qui, ma eta: 30 sarebbe un numero.
  • Booleani: attivo, notificheEmail.
  • Array: indirizzi (un array di oggetti annidati).
  • Oggetti Annidati: preferenze, e gli oggetti all'interno dell'array indirizzi.
  • ObjectID: _id (un identificatore univoco generato da MongoDB).
  • Date: dataRegistrazione (rappresentato come un oggetto ISODate).

La capacità di annidare documenti e array direttamente all'interno di un altro documento è una delle forze maggiori di MongoDB. Permette di modellare relazioni "has-a" (un utente ha degli indirizzi, un utente ha delle preferenze) in modo naturale e senza la necessità di join complessi al momento della lettura dei dati.

Operazioni CRUD Fondamentali: Interagire con Dati

Le operazioni CRUD (Create, Read, Update, Delete) sono il pane quotidiano di ogni sviluppatore che lavora con i database. MongoDB offre un set di metodi intuitivi per eseguire queste operazioni sui documenti all'interno delle collection.

Creazione (Create): insertOne() e insertMany()

Per aggiungere nuovi documenti a una collection, si usano i metodi insertOne() per un singolo documento o insertMany() per più documenti.

// Seleziona il database 'negozio'
use negozio

// Inserisce un singolo prodotto nella collection 'prodotti'
db.prodotti.insertOne({
  nome: "Smartphone X",
  marca: "TechCorp",
  prezzo: 799.99,
  specifiche: { cpu: "Octa-core", ram: "8GB", storage: "128GB" },
  disponibile: true,
  tags: ["elettronica", "smartphone", "offerta"]
})

// Inserisce più prodotti contemporaneamente
db.prodotti.insertMany([
  {
    nome: "Laptop Pro 15",
    marca: "CompTech",
    prezzo: 1299.00,
    specifiche: { cpu: "Intel i7", ram: "16GB", storage: "512GB SSD" },
    disponibile: true,
    tags: ["elettronica", "laptop", "premium"]
  },
  {
    nome: "Cuffie Bluetooth",
    marca: "AudioBlast",
    prezzo: 89.50,
    specifiche: { tipo: "over-ear", autonomia: "20h" },
    disponibile: false,
    tags: ["audio", "accessori"]
  }
])

Ogni operazione di inserimento restituirà un oggetto che include l'_id del/dei documento/i inserito/i, confermando l'avvenuta creazione.

Lettura (Read): find() e findOne()

Per recuperare documenti da una collection, si utilizzano i metodi find() per recuperare più documenti e findOne() per recuperare un singolo documento (il primo che soddisfa i criteri).

Il metodo find() accetta due argomenti opzionali: un oggetto di query per filtrare i documenti e un oggetto di proiezione per specificare quali campi includere o escludere.

// Trova tutti i prodotti nella collection 'prodotti'
db.prodotti.find()

// Trova un prodotto specifico per nome
db.prodotti.findOne({ nome: "Smartphone X" })

// Trova tutti i prodotti con marca "TechCorp" e prezzo inferiore a 800
db.prodotti.find({ marca: "TechCorp", prezzo: { $lt: 800 } })

// Trova tutti i prodotti disponibili con prezzo superiore a 1000, mostrando solo nome e prezzo
db.prodotti.find(
  { disponibile: true, prezzo: { $gt: 1000 } },
  { nome: 1, prezzo: 1, _id: 0 } // 1 per includere, 0 per escludere. _id è incluso di default.
)

// Trova prodotti che hanno il tag 'elettronica' O 'audio'
db.prodotti.find({ $or: [{ tags: "elettronica" }, { tags: "audio" }] })

// Paginazione: salta i primi 2 documenti e prendi i successivi 2, ordinati per prezzo
db.prodotti.find().sort({ prezzo: 1 }).skip(2).limit(2)

Operatori di Query Comuni:

  • $eq: uguale a (implicito se non specificato)
  • $ne: non uguale a
  • $gt: maggiore di
  • $gte: maggiore o uguale a
  • $lt: minore di
  • $lte: minore o uguale a
  • $in: il valore è in un array di possibili valori
  • $nin: il valore non è in un array di possibili valori
  • $and: operatori logici AND
  • $or: operatori logici OR
  • $not: operatori logici NOT
  • $exists: verifica l'esistenza di un campo
  • $regex: query basate su espressioni regolari

Aggiornamento (Update): updateOne(), updateMany(), replaceOne()

Per modificare documenti esistenti, si usano updateOne() per un singolo documento, updateMany() per più documenti o replaceOne() per sostituire completamente un documento.

Gli operatori di aggiornamento sono essenziali per modificare solo parti di un documento.

// Aggiorna il prezzo dello "Smartphone X"
db.prodotti.updateOne(
  { nome: "Smartphone X" },
  { $set: { prezzo: 749.99, ultimaModifica: new Date() } }
)

// Incrementa il prezzo di tutti i prodotti "TechCorp" del 10%
db.prodotti.updateMany(
  { marca: "TechCorp" },
  { $inc: { prezzo: 0.10 * db.prodotti.findOne({ marca: "TechCorp" }).prezzo } }
)

// Aggiunge un nuovo tag "best-seller" al Laptop Pro 15
db.prodotti.updateOne(
  { nome: "Laptop Pro 15" },
  { $push: { tags: "best-seller" } }
)

// Rimuove il tag "offerta" dallo Smartphone X
db.prodotti.updateOne(
  { nome: "Smartphone X" },
  { $pull: { tags: "offerta" } }
)

// Sostituisce completamente un documento (attenzione: rimuove tutti i campi non specificati)
db.prodotti.replaceOne(
  { nome: "Cuffie Bluetooth" },
  { nome: "Auricolari Wireless", marca: "AudioBlast", prezzo: 99.00, disponibile: true }
)

Operatori di Aggiornamento Comuni:

  • $set: imposta il valore di un campo. Se il campo non esiste, lo crea.
  • $unset: rimuove un campo dal documento.
  • $inc: incrementa il valore di un campo numerico.
  • $push: aggiunge un elemento a un array.
  • $pop: rimuove il primo o l'ultimo elemento di un array.
  • $pull: rimuove tutti gli elementi che corrispondono a un valore o una condizione da un array.

Eliminazione (Delete): deleteOne(), deleteMany()

Per rimuovere documenti da una collection, si usano deleteOne() per un singolo documento o deleteMany() per più documenti.

// Elimina il prodotto "Auricolari Wireless"
db.prodotti.deleteOne({ nome: "Auricolari Wireless" })

// Elimina tutti i prodotti non disponibili
db.prodotti.deleteMany({ disponibile: false })

// ATTENZIONE: Questo elimina TUTTI i documenti dalla collection 'prodotti'
db.prodotti.deleteMany({})

// Per eliminare l'intera collection
db.prodotti.drop()

È fondamentale prestare la massima attenzione quando si usano i metodi deleteMany() e drop(), specialmente in ambienti di produzione, poiché le eliminazioni sono permanenti e non reversibili senza un backup.

Esempi Pratici e Scenari d'Uso

Vediamo come i concetti di database, collection e documenti si applicano in scenari reali di programmazione web.

Scenario 1: Un'applicazione di E-commerce

Immaginiamo di dover modellare i dati per un'applicazione e-commerce. Potremmo avere un database chiamato ecommerce.

Collection utenti:

{
  "_id": ObjectId("..."),
  "nome": "Luca",
  "email": "luca@example.com",
  "passwordHash": "hashed_password",
  "indirizzi": [
    { "tipo": "spedizione", "via": "Via Garibaldi 1", "citta": "Roma", "cap": "00100" },
    { "tipo": "fatturazione", "via": "Via Garibaldi 1", "citta": "Roma", "cap": "00100" }
  ],
  "dataRegistrazione": ISODate("2023-01-01T10:00:00Z")
}

Collection prodotti:

{
  "_id": ObjectId("..."),
  "nome": "Maglietta Uomo",
  "descrizione": "Maglietta in cotone 100%",
  "prezzo": 25.00,
  "categoria": "Abbigliamento",
  "tags": ["uomo", "cotone", "t-shirt"],
  "varianti": [
    { "colore": "Rosso", "taglia": "M", "quantita": 10 },
    { "colore": "Blu", "taglia": "L", "quantita": 5 }
  ],
  "recensioni": [
    { "utenteId": ObjectId("..."), "voto": 5, "commento": "Ottima qualità!", "data": ISODate("2023-03-10T14:00:00Z") }
  ]
}

Collection ordini:

{
  "_id": ObjectId("..."),
  "utenteId": ObjectId("..."),
  "dataOrdine": ISODate("2023-03-15T11:30:00Z"),
  "stato": "in elaborazione",
  "articoli": [
    { "prodottoId": ObjectId("..."), "nome": "Maglietta Uomo", "variante": { "colore": "Rosso", "taglia": "M" }, "quantita": 1, "prezzoUnitario": 25.00 },
    { "prodottoId": ObjectId("..."), "nome": "Laptop Pro 15", "quantita": 1, "prezzoUnitario": 1299.00 }
  ],
  "totale": 1324.00,
  "indirizzoSpedizione": { "via": "Via Garibaldi 1", "citta": "Roma", "cap": "00100" }
}

Perché questa modellazione è efficace in MongoDB?

  • Utenti: Gli indirizzi multipli e le preferenze possono essere annidati direttamente nel documento utente, evitando join per recuperare informazioni comuni. Questo rende il recupero del profilo utente un'operazione singola e veloce.
  • Prodotti: Le varianti (taglia, colore) e le recensioni sono parte integrante del prodotto. Non è necessario creare tabelle separate e join complessi. Quando recuperi un prodotto, hai subito tutte le sue informazioni, incluse le recensioni e le varianti disponibili. Questo è un esempio perfetto di come la denormalizzazione in MongoDB può migliorare le performance di lettura.
  • Ordini: Gli articoli dell'ordine e l'indirizzo di spedizione sono inclusi direttamente nel documento dell'ordine. Questo garantisce che l'ordine sia un'unità completa e immutabile una volta creato, e che tutte le informazioni necessarie siano disponibili senza dover interrogare altre collection, il che è fondamentale per la consistenza e la velocità di recupero degli ordini passati.

Scenario 2: Un sistema di gestione contenuti (CMS)

Consideriamo un blog o un CMS. Avremmo un database blog.

Collection posts:

{
  "_id": ObjectId("..."),
  "titolo": "Introduzione a MongoDB",
  "slug": "introduzione-mongodb",
  "contenuto": "Il testo completo dell'articolo...",
  "autoreId": ObjectId("..."),
  "dataPubblicazione": ISODate("2023-02-20T09:00:00Z"),
  "tags": ["mongodb", "nosql", "database"],
  "commenti": [
    { "_id": ObjectId("..."), "utente": "Giovanni", "testo": "Ottimo articolo!", "data": ISODate("2023-02-20T10:15:00Z") },
    { "_id": ObjectId("..."), "utente": "Maria", "testo": "Molto chiaro, grazie.", "data": ISODate("2023-02-20T11:00:00Z") }
  ],
  "status": "pubblicato"
}

In questo caso, i commenti sono annidati direttamente nel documento del post. Questo è ideale se i commenti sono sempre recuperati insieme al post e non richiedono query o aggiornamenti indipendenti su larga scala. Se i commenti dovessero essere estremamente numerosi o richiedere una gestione indipendente (moderazione complessa, ricerca avanzata), si potrebbe optare per una collection commenti separata, mantenendo un riferimento (postId) al post.

Questi esempi illustrano la flessibilità di MongoDB nel modellare relazioni uno-a-molti e molti-a-molti, spesso senza la necessità di join espliciti, a differenza dei database relazionali. La scelta di annidare o referenziare documenti dipende molto dai pattern di accesso ai dati dell'applicazione.

Errori Comuni e Migliori Pratiche

L'adozione di un database NoSQL come MongoDB porta con sé nuove opportunità, ma anche nuove sfide e potenziali errori se non si comprendono appieno i suoi principi.

1. Mancata Comprensione del Campo _id

Errore: Non considerare l'_id come la chiave primaria universale. Tentare di usare altri campi come identificatori primari senza indicizzazione adeguata o senza garantirne l'unicità. Soluzione: L'_id è garantito essere univoco all'interno di una collection e indicizzato di default. Usalo sempre come identificatore principale. Se hai bisogno di un altro campo univoco (es. email per gli utenti), assicurati di creare un indice univoco su quel campo.

2. Design di Collection Inefficiente (Over-embedding o Over-referencing)

Errore: Annidare troppi dati (over-embedding) o troppi pochi dati (over-referencing).

  • Over-embedding: Mettere troppi dati annidati in un singolo documento, rendendolo troppo grande (il limite di dimensione di un documento è 16MB) o rendendo gli aggiornamenti complessi se solo una piccola parte dei dati annidati cambia frequentemente.
  • Over-referencing: Trattare MongoDB come un RDBMS, creando troppe collection separate e utilizzando solo riferimenti (_id di altri documenti) dove l'embedding sarebbe più efficiente. Questo porta a molte query separate per recuperare un singolo oggetto logico, annullando i vantaggi di performance.

Soluzione: Il design del modello dati è cruciale in MongoDB. Pensa ai tuoi pattern di accesso ai dati. Se i dati vengono quasi sempre recuperati insieme, l'embedding è probabilmente la scelta migliore. Se i dati sono molto grandi, cambiano frequentemente o vengono spesso interrogati indipendentemente, i riferimenti sono più appropriati. MongoDB è flessibile, ma richiede una buona strategia di modellazione.

3. Ignorare gli Indici

Errore: Non creare indici sui campi usati nelle query find(), sort(), e join (se usi $lookup nell'aggregazione). Soluzione: Senza indici, MongoDB deve eseguire una scansione completa della collection (collection scan) per trovare i documenti corrispondenti, il che è estremamente inefficiente su grandi dataset. Identifica i campi su cui effettui le query più frequentemente e crea indici appropriati. Gli indici sono fondamentali per le performance, proprio come nei database relazionali.

4. Query Inefficienti

Errore: Scrivere query che non sfruttano gli indici o che sono troppo generiche. Soluzione: Usa explain() per analizzare le tue query e capire come MongoDB le esegue. Cerca di rendere le tue query il più specifiche possibile per ridurre il numero di documenti da scansionare.

5. Non Considerare la Consistenza dei Dati

Errore: Assumere che MongoDB gestisca la consistenza dei dati come un RDBMS, ignorando il modello di consistenza eventuale per le operazioni distribuite o non utilizzando le transazioni multi-documento quando necessarie. Soluzione: Per singole operazioni su un singolo documento, MongoDB fornisce atomicità. Per operazioni che coinvolgono più documenti o più collection, a partire da MongoDB 4.0, sono disponibili le transazioni multi-documento. Usale quando la consistenza forte è un requisito critico per le operazioni che modificano più documenti.

Prossimi Passi: Oltre le Basi

Questa lezione ha posto le fondamenta per comprendere la struttura dei dati in MongoDB e come manipolarli attraverso le operazioni CRUD. Ma il viaggio è appena iniziato! Per consolidare e approfondire la vostra conoscenza, vi suggerisco i seguenti prossimi passi:

  1. Indici Avanzati: Approfondite i diversi tipi di indici disponibili in MongoDB (singolo campo, composti, multi-key, testuali, geospaziali, TTL) e imparate a usarli per ottimizzare le performance delle vostre query. Gli indici sono la chiave per un'applicazione performante.
  2. Framework di Aggregazione: Il framework di aggregazione di MongoDB è uno strumento estremamente potente per elaborare e trasformare i dati. Permette di eseguire operazioni complesse come raggruppamento, filtraggio, proiezione e join (tramite $lookup) su grandi volumi di dati. È l'equivalente NoSQL delle query SQL più complesse e delle viste.
  3. Modellazione Avanzata dei Dati: Studiate i pattern di modellazione dei dati comuni in MongoDB, come il pattern "Embedded Documents", "References", "Atomic Updates" e "Tree Structures". Capire quando usare un pattern rispetto a un altro è fondamentale per costruire applicazioni scalabili e performanti.
  4. Driver per Linguaggi di Programmazione: Iniziate a integrare MongoDB con il vostro linguaggio di programmazione preferito (Node.js con Mongoose, Python con PyMongo, Java con il driver Java, PHP con il driver MongoDB, ecc.). Questo vi permetterà di costruire applicazioni reali e di vedere come i comandi della shell si traducono in codice programmatico.
  5. Replication e Sharding: Per applicazioni ad alta disponibilità e scalabilità orizzontale, è essenziale comprendere come funzionano i Replica Set (per la ridondanza e il failover) e lo Sharding (per distribuire i dati su più server). Questi concetti sono avanzati ma cruciali per la produzione.

Continuando a esplorare queste aree, diventerete esperti nella progettazione e gestione di applicazioni basate su MongoDB, sfruttando appieno la sua flessibilità e le sue capacità di performance. Il mondo della programmazione web è in continua evoluzione, e la padronanza di database NoSQL come MongoDB è una competenza sempre più richiesta e preziosa.

Spero che questa lezione vi sia stata utile per capire a fondo la struttura di MongoDB e come iniziare a manipolare i vostri dati. Nella prossima lezione, approfondiremo ulteriormente le query e come estrarre informazioni significative dai vostri documenti.