Cos'è un database? Una guida per chi crea app

Un database è un archivio organizzato di informazioni che un'app salva e da cui legge — i suoi utenti, ordini, prenotazioni, messaggi. A differenza delle informazioni tenute solo in una scheda del browser, i dati in un database restano disponibili dopo un aggiornamento o un riavvio, e tutti quelli che usano l'app vedono gli stessi record. La maggior parte dei database organizza i dati in tabelle, un po' come i fogli di un foglio di calcolo, ma con regole rigorose che mantengono i dati coerenti.

Perché è importante quando crei con l'AI

La sorpresa più comune per chi crea con l'AI è un'app che sembra finita ma dimentica tutto. Aggiungi un cliente, aggiorni la pagina e non c'è più. Di solito significa che l'app teneva i dati nella memoria del browser, non in un database.

Un database è anche il luogo dove vivono molte delle decisioni più importanti, che tu te ne renda conto o no:

Cosa registri. Se non memorizzi lo stato di una prenotazione, non puoi mostrare quali prenotazioni sono state annullate.
Come le cose si collegano. Se un cliente possa avere molte prenotazioni, o una prenotazione molti servizi, determina l'intera struttura dell'app.
Chi può vedere cosa. La maggior parte degli errori di privacy riguarda quali record un utente può leggere.

Non devi progettare tu il database. Ma capirne le basi ti permette di descrivere chiaramente i tuoi dati e di individuare i problemi in anticipo.

Un'analogia di tutti i giorni

Immagina uno schedario ben tenuto in un piccolo ufficio.

Ogni cassetto contiene un solo tipo di cosa: un cassetto per i clienti, uno per gli appuntamenti, uno per le fatture. Dentro ogni cassetto, ogni cartella segue lo stesso formato, con gli stessi campi compilati. Ogni cartella ha un numero di riferimento unico, e quando una fattura appartiene a un cliente, la cartella della fattura riporta il numero di quel cliente invece di fotocopiarne l'intero fascicolo.

Questo è un database relazionale. I cassetti sono tabelle, le cartelle sono righe, i campi sono colonne, i numeri di riferimento sono chiavi primarie, e le annotazioni che rimandano a un'altra cartella sono chiavi esterne. Un buon responsabile d'ufficio fa anche rispettare delle regole — nessun appuntamento senza data, nessun due clienti con lo stesso numero — proprio come fa un database.

Un esempio pratico: un'app di prenotazioni per un salone

Supponi di chiedere a un'AI di costruire un sito di prenotazioni per un salone di parrucchiere. Un database sensato avrebbe quattro tabelle.

servizi

id	nome	durata_minuti	prezzo
1	Taglio	45	40,00
2	Colore	90	95,00

personale

id	nome	email
1	Sara	sara@example.com
2	Omar	omar@example.com

clienti

id	nome	email	telefono
101	Lena Park	lena@example.com	555-0100

prenotazioni

id	cliente_id	servizio_id	personale_id	inizia_alle	stato
5001	101	1	2	2026-10-03 14:00	confermata

Guarda la tabella prenotazioni. Non copia il nome e il telefono di Lena in ogni prenotazione; memorizza cliente_id = 101. Se Lena cambia numero di telefono, la modifica avviene in un unico punto e ogni prenotazione mostra quello nuovo. Questa è l'idea centrale di un database relazionale: memorizza ogni fatto una sola volta e collegalo dove serve.

La stessa struttura risponde a domande utili:

"Quali orari sono liberi per Omar venerdì?" — guarda le prenotazioni di Omar quel giorno.
"Quanto hanno incassato i colori questo mese?" — collega le prenotazioni ai servizi e somma i prezzi.
"Quali clienti non prenotano da 90 giorni?" — confronta i clienti con la loro ultima prenotazione.

Termini comuni spiegati

Termine	Significato
Tabella	Una raccolta di un solo tipo di record, come clienti o prenotazioni.
Riga (record)	Un elemento di una tabella — un cliente, una prenotazione.
Colonna (campo)	Un'informazione che ogni riga possiede, come email o prezzo.
Chiave primaria	Un ID unico per ogni riga, di solito un numero o una stringa casuale.
Chiave esterna	Una colonna che punta a una riga di un'altra tabella, come `cliente_id` nelle prenotazioni.
Schema	Il disegno complessivo: quali tabelle esistono, le loro colonne e come si collegano.
Query	Una richiesta di lettura o modifica dei dati, come "tutte le prenotazioni di domani".
SQL	Structured Query Language, il linguaggio standard per interrogare i database relazionali.
Migrazione	Una modifica salvata e ripetibile dello schema, come l'aggiunta di una colonna.
Indice	Una struttura di ricerca che rende più veloci le ricerche su una colonna, come l'indice di un libro.
CRUD	Create, Read, Update, Delete — le quattro operazioni base che le app fanno sui dati.
Backup	Una copia dei dati da cui ripristinare in caso di problemi.

Tipi di database

Tipo	Come conserva i dati	Esempi	Adatto a
Relazionale (SQL)	Tabelle con colonne fisse e collegamenti tra di esse	Postgres, MySQL, SQLite	La maggior parte delle app aziendali: prenotazioni, negozi, CRM, SaaS
Documentale (NoSQL)	Documenti flessibili in stile JSON	MongoDB, Firestore	Dati la cui forma varia molto da record a record
Chiave-valore	Un valore conservato sotto una chiave	Redis	Cache, dati di breve durata come le sessioni

Per quasi tutto ciò che un imprenditore o una piccola attività costruisce per primo, un database relazionale è la scelta predefinita sicura.

Dove si colloca il database nella tua app

I visitatori non parlano mai direttamente con il database. La pagina nel loro browser (il frontend) chiede i dati al tuo server (il backend), di solito tramite un'API. Il server verifica chi chiede e se ne ha il diritto, poi interroga il database e restituisce solo ciò che quella persona può vedere.

Quel passaggio intermedio è importante. Se il browser potesse interrogare il database direttamente con pieno accesso, chiunque potrebbe aprire gli strumenti per sviluppatori e leggere tutto.

Errori comuni e idee sbagliate

Tenere i dati solo nel browser. L'archiviazione del browser (come localStorage) vive su un solo dispositivo e in un solo browser. Va bene per un filtro ricordato, non per gli ordini.
Mettere tutto in un'unica tabella. Una sola tabella "prenotazioni" con nome, telefono e prezzo del servizio del cliente copiati in ogni riga si disallinea in fretta.
Conservare le password in chiaro. Le password vanno sottoposte ad hash, mai conservate leggibili. Vedi cos'è l'autenticazione.
Nessuna regola sui dati. Senza campi obbligatori e regole di unicità, ti ritroverai con prenotazioni senza data e clienti duplicati.
Dimenticare le eliminazioni. Decidi se eliminare un cliente elimina anche le sue prenotazioni, le conserva o è bloccato.
Usare i dati di produzione per sperimentare. Prova prima le modifiche rischiose in un ambiente sicuro, e conserva dei backup.
Considerare il foglio di calcolo come database per sempre. I fogli di calcolo sono ottimi per iniziare, ma faticano con molti utenti simultanei e permessi. Vedi come trasformare un foglio di calcolo in un'app.

Cosa chiedere al tuo creatore di app con l'AI

"Salva questo in un database, non nel browser. Dimmi quali tabelle creerai."
"Mostrami lo schema come una semplice tabella: ogni tabella, le sue colonne e come si collegano."
"Un cliente può avere molte prenotazioni; ogni prenotazione ha esattamente un servizio e un membro del personale."
"Rendi l'email obbligatoria e unica per i clienti."
"Impedisci che due prenotazioni per lo stesso membro del personale si sovrappongano."
"Solo il proprietario autenticato può leggere tutte le prenotazioni; i clienti vedono solo le proprie. Applicalo sul server."
"Quando elimino un servizio, non cancellare le prenotazioni passate — segna invece il servizio come inattivo."

Database in Mythex

Quando la tua app deve salvare dati, Mythex aggiunge al progetto un database Postgres dedicato — puoi chiederlo in chat ("salva le iscrizioni alla lista d'attesa in un database") o usare il comando /database. I dettagli di connessione vengono passati automaticamente alla tua app, e l'agente crea le tabelle. Il database va in pausa dopo cinque minuti di inattività e si riattiva alla richiesta successiva; per le app pubblicate si paga il tempo in cui è stato attivo, con lo stesso saldo di crediti usato per la creazione. È disponibile nei piani Free e Pro. La documentazione del database ne descrive i dettagli, e i template di app includono punti di partenza basati sui dati.

Domande

Cos'è un database in parole semplici?

Un database è un archivio organizzato di informazioni in cui un'app può salvare e da cui può leggere, come utenti, ordini o prenotazioni. A differenza dei dati tenuti solo in una scheda del browser, restano disponibili dopo un aggiornamento, un riavvio o quando qualcuno apre l'app da un altro dispositivo.

Un foglio di calcolo è un database?

Un foglio di calcolo può contenere lo stesso tipo di dati, ma non è pensato per le app. Un vero database fa rispettare regole su ciò che contiene ogni colonna, collega le tabelle in modo affidabile, gestisce molte persone che scrivono contemporaneamente e controlla chi può leggere cosa.

Qual è la differenza tra database SQL e NoSQL?

I database SQL (relazionali) come Postgres e MySQL conservano i dati in tabelle con colonne definite e relazioni tra di esse. I database NoSQL come MongoDB conservano documenti più flessibili. La maggior parte delle app aziendali — prenotazioni, CRM, negozi — si adatta bene al modello relazionale.

La mia app ha bisogno di un database?

Se deve ricordare qualsiasi cosa inserita dalle persone — iscrizioni, ordini, messaggi, impostazioni — e mostrarla più tardi o a qualcun altro, sì. Un sito puramente informativo senza moduli che salvano dati di solito non ne ha bisogno.