I 7 concetti fondamentali da conoscere per iniziare con MongoDB

MongoDB è un database NoSQL che usa un approccio flessibile, basato su documenti, per archiviare i dati in documenti simili a JSON organizzati in raccolte. In breve, significa che, quando lavori con MongoDB, i tuoi dati sono salvati in un formato che assomiglia molto a JSON. Questo li rende facili da leggere, semplici da mappare nel codice e scalabili. MongoDB è moderno e segue un approccio diverso rispetto ai database relazionali. I database relazionali archiviano i dati usando righe nelle tabelle. Questo approccio ha i suoi vantaggi, ma una delle principali difficoltà è creare relazioni usando tabelle aggiuntive. MongoDB risolve questo problema introducendo uno schema flessibile in cui i dati sono archiviati in raccolte e non in tabelle. Ciò significa che i dati relativi a un oggetto possono essere salvati insieme all’oggetto stesso. In questo tutorial, esploreremo sette concetti che chi inizia con MongoDB dovrebbe conoscere. Detto questo, iniziamo.

Capire NoSQL e i database a documenti

Quando la maggior parte delle persone pensa ai database, pensa a SQL, che archivia i dati usando righe, tabelle e relazioni. Questo è ottimo per molte applicazioni, soprattutto quando i dati dell’applicazione sono strutturati. Ma può risultare limitante quando i dati non si adattano perfettamente a una struttura a tabella.

Ed è qui che entra in gioco il NoSQL, che significa semplicemente “non solo SQL”. Indica una famiglia di database che si allontanano dal rigido modello a tabelle per offrire più flessibilità. Invece di forzare tutti i tuoi dati in colonne predefinite, puoi strutturarli in un modo che rispecchia come funziona davvero la tua applicazione.

MongoDB è un database a documenti, uno dei tipi di database NoSQL più diffusi. Invece di righe e tabelle, i dati sono salvati come documenti nelle raccolte. Ogni documento assomiglia molto a JSON, con coppie chiave-valore, array e persino oggetti annidati. Questo rende facilissimo rappresentare dati del mondo reale. Un buon esempio è un profilo utente con indirizzi e preferenze in un unico record, senza doverlo distribuire su più tabelle. Vediamo come appare un profilo utente con indirizzi e preferenze in un singolo record in MongoDB.

{
"_id": "u123",
"name": "Moses Anu",
"email": "moses@example.com",
"addresses": [
{ "type": "home", "city": "Abuja" },
{ "type": "work", "city": "Lagos" }
],
"preferences": {
"language": "English",
"theme": "dark"
}
}

Nozioni di base sull’architettura di MongoDB

Per lavorare in modo efficace con MongoDB, è utile comprendere come sono organizzati i dati in un database MongoDB. A differenza dei database SQL, dove i dati sono strutturati in tabelle e righe, MongoDB usa raccolte e documenti.

• Database: Pensalo come il contenitore di tutto. Proprio come potresti avere più database in MySQL, anche MongoDB offre la flessibilità di più database per progetti o applicazioni diverse.
• Collection: All’interno di ogni database ci sono le raccolte. Pensa a una raccolta come a una tabella con uno schema molto flessibile. Questo perché le “tabelle” di MongoDB non impongono uno schema rigido. Puoi inserire nella stessa raccolta documenti con campi diversi.
• Document: È qui che avviene la vera magia. Un documento è un oggetto simile a JSON (in realtà, sotto il cofano è BSON) che contiene i tuoi dati. I documenti possono avere oggetti annidati e array, risultando molto più naturali da usare nelle app moderne. Parleremo di BSON nel prossimo paragrafo.

Per capire meglio l’architettura di MongoDB, facciamo un esempio. Supponiamo di costruire una semplice app di e-commerce usando MongoDB. I nostri dati seguirebbero la struttura seguente.

• Avere un database chiamato shopDB.
• Al suo interno, una raccolta chiamata products.
• E dentro quella raccolta, documenti che rappresentano ogni prodotto con dettagli come nome, prezzo e categoria.

Lo schema flessibile

Per capire meglio il concetto di schema flessibile, riprendendo l’esempio sopra, sappi che un prodotto può avere un campo sconto mentre un altro no. MongoDB non obbliga ogni prodotto ad avere esattamente gli stessi campi. Questa flessibilità è uno dei motivi per cui gli sviluppatori amano MongoDB, soprattutto quando costruiscono applicazioni che evolvono rapidamente.

BSON e tipi di dato

Se hai già lavorato con JSON, MongoDB ti sembrerà molto naturale. In realtà, MongoDB non archivia i dati come puro JSON. MongoDB usa qualcosa chiamato BSON. BSON sta per Binary JSON.

Cos’è il BSON e perché MongoDB lo usa?

BSON è come il cugino più intelligente ed efficiente di JSON. Mantiene la stessa struttura leggibile a chiave-valore che gli sviluppatori amano, ma aggiunge alcune super-caratteristiche:

• Supporta più tipi di dato rispetto a JSON (come date, decimali e binari grezzi).
• È ottimizzato per codifica/decodifica veloce, cosa che rende più rapide le query in MongoDB.
• Archivia tutto in un formato binario compatto, più efficiente per grandi quantità di dati.

In pratica, BSON offre a MongoDB la flessibilità di JSON più le prestazioni e la precisione di cui i database hanno bisogno.

Tipi di dato BSON comuni

MongoDB supporta un’ampia gamma di tipi di dato, ma ecco i più comuni con i loro esempi:

• String: "name": "Alice"
• Number: "age": 28
• Boolean: "isActive": true
• Date: "createdAt": ISODate("2025-08-18T10:00:00Z")
• Array: "skills": ["MongoDB", "Node.js", "React"]
• Documento incorporato. Oggetti annidati all’interno dei documenti:

"address": { 
  "city": "Lagos", 
  "country": "Nigeria" 
}

• ObjectId: tipo di ID speciale che MongoDB usa per gli ID univoci dei documenti. ObjectId("64f5c9e8a5f76b1d2c3a4567")

Vediamo un esempio di documento profilo utente in formato BSON archiviato in MongoDB:

{
  "_id": ObjectId("64f5c9e8a5f76b1d2c3a4567"),
  "name": "Moses",
  "age": 30,
  "isActive": true,
  "skills": ["Laravel", "MongoDB", "Vue"],
  "address": {
    "city": "Abuja",
    "country": "Nigeria"
  },
  "createdAt": ISODate("2025-08-18T10:00:00Z")
}

Alcune cose da notare:

• Il campo _id è generato automaticamente come ObjectId se non lo imposti tu.
• Le date sono salvate come ISODate, non come semplici stringhe.
• Il documento annidato address e l’array skills mostrano la flessibilità di MongoDB rispetto alle righe piatte di SQL.

Principi di progettazione dello schema

MongoDB ti permette di far evolvere il modello dati man mano che l’app cresce grazie al suo schema flessibile. Tuttavia, senza una corretta progettazione dello schema, lo schema flessibile di MongoDB può diventare rapidamente disordinato. Non dovresti buttare via la struttura solo perché MongoDB offre uno schema flessibile. Vediamo alcuni principi di progettazione dello schema da usare con MongoDB.

Schema flessibile vs. schema-less

MongoDB viene spesso descritto come schema-less, ma è un po’ fuorviante. Ogni documento ha uno schema: semplicemente non è imposto a livello di database, a meno che tu non scelga di aggiungere regole di validazione.

Per esempio, due documenti nella stessa raccolta users potrebbero tecnicamente apparire molto diversi:

// Document 1
{ "name": "Alice", "email": "alice@example.com" }

// Document 2
{ "username": "Bob123", "age": 29 }

Questa flessibilità può essere ottima durante il prototyping rapido, ma in produzione di solito vorrai un po’ di coerenza. È qui che entra in gioco la validazione JSON Schema. Puoi imporre certe regole per non ritrovarti con dati disordinati e inaffidabili.

Incorporare vs. referenziare documenti

Un’altra decisione importante nella progettazione dello schema in MongoDB è come modellare le relazioni. Vediamo alcuni modi in cui le relazioni possono essere modellate in un documento MongoDB.

Embedding (annidare dati dentro un documento)

MongoDB supporta l’incorporamento di documenti in una raccolta. Questo approccio è ideale per dati che vengono consultati insieme. Un esempio può essere un post del blog con i commenti salvati direttamente al suo interno. Di seguito un esempio di embedding dei dati.

{
  "title": "Intro to MongoDB",
  "comments": [
    { "user": "Alice", "text": "Great post!" },
    { "user": "Bob", "text": "Very helpful." }
  ]
}

I dati archiviati in questo modo hanno prestazioni migliori e richiedono meno query per essere recuperati o elaborati. Se non strutturati correttamente, però, possono portare a documenti troppo pesanti.

Referencing (collegamenti tra documenti)

Quando la dimensione dei dati correlati cresce molto o viene riutilizzata spesso, è consigliabile collegare i dati tra documenti. Questo è noto come referencing.

Un esempio può essere un post del blog con molti commenti. In questo caso, possiamo salvare solo gli ID dei commenti, mentre i commenti veri e propri vivono nella loro raccolta. Il codice sotto è un esempio di questo approccio.

// Blog post
{ "title": "Intro to MongoDB", "commentIds": [ObjectId("..."), ObjectId("...")] }

// Separate comment document
{ "_id": ObjectId("..."), "user": "Alice", "text": "Great post!" }

Strutturare i dati in questo modo mantiene i documenti più piccoli, evita duplicazioni e rende il codice più manutenibile. Tuttavia, richiede più query (anche se puoi usare i join $lookup nell’aggregazione).

Evitare gli errori comuni di schema design

Over-embedding: Poiché MongoDB ha uno schema flessibile, è facile infilare tutto in un unico documento gigantesco. Non è consigliabile e può portare a scarse prestazioni. MongoDB impone una dimensione massima di 16 MB per documento per garantire che gli sviluppatori strutturino correttamente i dati nei documenti.

Ignorare gli indici: Non ignorare gli indici quando lavori con MongoDB. Se le tue query non sono allineate al design dello schema, finirai con ricerche lente. Progetta sempre pensando ai pattern di accesso.

Trattare MongoDB come SQL: Va bene suddividere i dati in documenti piccoli. Tuttavia, ricorda che MongoDB ha uno schema flessibile: non trattarlo come un database relazionale. Se copi 1:1 il tuo schema relazionale in MongoDB (molte tabelle/raccolte piccole e normalizzate), perdi i vantaggi del modello a documenti.

Prenditi il tempo per pianificare gli schemi. Uno schema ben pensato può influire enormemente sulle prestazioni della tua applicazione.

Validazione dei dati

MongoDB è flessibile. Questo può facilmente portare a dati non strutturati e disorganizzati se non si presta attenzione. È qui che entra in gioco la validazione dei dati.

Pensa alla validazione come alla definizione di regole di base per le tue raccolte. Garantisce che ogni documento inserito o aggiornato rispetti certe regole, ad esempio richiedere il campo email o assicurarsi che “age” sia sempre un numero.

Usare la validazione JSON Schema in MongoDB

MongoDB supporta JSON Schema per la validazione. JSON Schema è uno standard per descrivere la forma dei tuoi documenti. Alcune regole che possono essere applicate includono:

• Campi obbligatori.
• Tipi di dato (stringa, numero, data, ecc.).
• Intervalli di valori o pattern di stringa.

La validazione dei dati può darci il meglio dei due mondi quando lavoriamo con MongoDB. Lo schema flessibile di MongoDB più dei binari di protezione aiutano a mantenere i dati puliti.

Applicare regole per mantenere i dati puliti

Poniamo di avere una raccolta users. Vogliamo assicurarci che:

• Ogni utente abbia un nome (stringa).
• Ogni utente abbia un’email (stringa, dall’aspetto di un’email).
• Se age esiste, dev’essere un numero maggiore o uguale a 18.

Ecco come potremmo applicarlo con un validatore JSON Schema:

db.createCollection("users", {
  validator: {
    $jsonSchema: {
      bsonType: "object",
      required: ["name", "email"],
      properties: {
        name: {
          bsonType: "string",
          description: "must be a string and is required"
        },
        email: {
          bsonType: "string",
          pattern: "^.+@.+\\..+$",
          description: "must be a valid email address"
        },
        age: {
          bsonType: "int",
          minimum: 18,
          description: "must be an integer greater than or equal to 18"
        }
      }
    }
  }
})

MongoDB garantisce che solo i dati validati vengano salvati nella raccolta. 

Operazioni CRUD

Al cuore del lavoro con MongoDB ci sono quattro operazioni di base: create, read, update e delete, meglio note come CRUD.

Se sai fare CRUD, puoi costruire quasi qualsiasi applicazione. MongoDB lo rende semplice con una manciata di metodi intuitivi. Vediamoli uno per uno.

Create

Per aggiungere un nuovo documento a una raccolta in MongoDB, usi il metodo insertOne(). Ad esempio, possiamo creare un nuovo documento utente nella raccolta user usando il codice sotto.

db.users.insertOne({
  name: "Alice",
  email: "alice@example.com",
  age: 25
})

MongoDB genera automaticamente un _id univoco per ogni documento creato.

Read

Leggere i dati da una raccolta è semplice. Usiamo find(). Possiamo ottenere tutti i documenti o filtrare con condizioni. Il codice seguente trova tutti gli utenti da una raccolta user.

// Find all users
db.users.find()

Possiamo filtrare usando una chiave univoca, per esempio un’email.

// Find one user by email
db.users.find({ email: "alice@example.com" })

find() restituisce sempre un cursore (su cui puoi iterare). Se vuoi una singola corrispondenza, puoi usare indOne().

Update

Una volta creati i dati, può essere necessario modificarli. Per modificare i dati si usa il metodo ``` updateOne()```. Si specifica un filtro e le modifiche da applicare.

// Update Alice’s age
db.users.updateOne(
  { email: "alice@example.com" },
  { $set: { age: 26 } }
)

L’operatore $set aggiorna solo il campo specificato, lasciando invariato il resto del documento.

Delete

Infine, possiamo rimuovere documenti con deleteOne() o deleteMany(). L’esempio seguente mostra un’azione deleteOne.

// Delete Alice’s record
db.users.deleteOne({ email: "alice@example.com" })

Nota che le eliminazioni sono permanenti.

Con sole queste quattro operazioni puoi costruire di tutto, dalle to-do app alle piattaforme di e-commerce.

Best practice per la sicurezza

La sicurezza non dovrebbe mai essere un ripensamento quando si parla di database. Detto ciò, vediamo le best practice fondamentali che chi inizia dovrebbe conoscere.

Autenticazione e autorizzazione

Per impostazione predefinita, una nuova installazione di MongoDB potrebbe non imporre l’autenticazione. Ciò significa che chiunque possa connettersi potrebbe potenzialmente accedere ai tuoi dati. Questo può essere un enorme rischio se non gestito. Per non lasciare MongoDB aperto, possiamo implementare autenticazione e autorizzazione.

• Autenticazione garantisce che si connettano solo utenti validi.
• Autorizzazione garantisce che anche gli utenti autenticati possano eseguire solo le azioni consentite.

Per esempio, invece di effettuare l’accesso ovunque come utente root/admin, dovresti creare utenti dedicati per compiti specifici.

// Create a new user with read-only access
db.createUser({
  user: "reportViewer",
  pwd: "strongPassword123",
  roles: [ { role: "read", db: "salesDB" } ]
})

Ora, questo utente può solo leggere i dati da salesDB, non scrivere o cancellare.

Controllo degli accessi basato sui ruoli (RBAC)

MongoDB usa i ruoli per gestire ciò che gli utenti possono fare. Alcuni ruoli predefiniti includono:

• Read: gli utenti con questo privilegio possono solo visualizzare i dati.
• ReadWrite: gli utenti con questo privilegio possono visualizzare e modificare i dati.
• DbAdmin: gli utenti con questo privilegio possono gestire indici, statistiche e profiling.
• Root: gli utenti con questo privilegio hanno il controllo completo. Evita di usarlo nel lavoro quotidiano!

Seguire il principio del privilegio minimo fornisce all’utente i permessi necessari per svolgere il proprio lavoro, garantendo al contempo la sicurezza del database MongoDB.

Evitare l’esposizione pubblica

Uno degli errori più comuni per chi inizia è lasciare MongoDB in ascolto sulla porta predefinita (27017) e vincolato a 0.0.0.0 (tutte le interfacce di rete).

Significa che il tuo database è aperto a tutto internet. Per evitarlo, dovresti adottare le seguenti misure:

• Vincola MongoDB solo a localhost o a un IP privato/interno.
• Usa un firewall (o security group nel cloud) per limitare l’accesso.
• Connettiti sempre tramite VPN o tunnel SSH se serve accesso remoto.

# Example: /etc/mongod.conf

net:

  port: 27017

  bindIp: 127.0.0.1   # Only accessible locally

Con queste pratiche, il tuo deployment MongoDB sarà molto più sicuro contro fughe accidentali o attacchi malevoli.

Conclusione

MongoDB si è guadagnato un posto tra i migliori database per le applicazioni moderne grazie alla sua flessibilità e alla sua potenza. Che tu stia sperimentando con un progetto personale o gestendo un sistema su larga scala, avere una solida padronanza dei fondamenti ti farà risparmiare un sacco di tempo e ti renderà più produttivo. In questo articolo, abbiamo esplorato i seguenti sette concetti chiave che chi inizia dovrebbe conoscere quando lavora con MongoDB. Includono

• Comprendere NoSQL e i database a documenti.
• Nozioni di base sull’architettura di MongoDB.
• BSON e tipi di dato.
• Principi di progettazione dello schema.
• Validazione dei dati.
• Operazioni CRUD.
• Best practice per la sicurezza.

Una buona comprensione dei concetti sopra ti darà basi solide quando lavori con MongoDB. Per maggiori dettagli, dai un’occhiata alla documentazione di MongoDB e al corso di DataCamp Introduzione a MongoDB in Python.