Come aggiungere un database alla tua app (senza perdere dati più avanti)

Per aggiungere un database alla tua app, scegli un database relazionale gestito (di solito si usa Postgres), conserva la sua stringa di connessione in un segreto lato server, crea una tabella per ogni tipo di elemento che la tua app salva e fai in modo che sia il tuo backend — mai il browser — a leggere e scrivere su di esso. Se costruisci con un app builder basato sull'AI, di solito basta scrivere «salva questo in un database» e l'agente crea le tabelle e il codice; il tuo compito è descrivere i dati in modo chiaro e verificare che vengano davvero salvati.

Questa guida spiega quando serve un database, le opzioni principali, come descrivere i tuoi dati e gli errori che causano perdite o esposizioni di dati.

Quando la tua app ha bisogno di un database

Ti serve un database quando la tua app deve ricordare qualcosa dopo che la pagina è stata chiusa, oppure condividere dati tra più persone. Segnali tipici:

• I visitatori inviano qualcosa: un modulo, una registrazione, una prenotazione, un ordine
• Gli utenti hanno account con contenuti salvati personali
• Un amministratore deve vedere o modificare ciò che hanno creato gli altri
• Vuoi report o conteggi nel tempo

Non ti serve un database per un sito statico in cui tutti vedono gli stessi contenuti, come un portfolio o una semplice landing page. Se non sai bene cos'è un database, leggi prima cos'è un database.

Le tue opzioni

Per la maggior parte delle piccole e medie web app, un database relazionale come Postgres è la scelta giusta. È bravo con le relazioni (un cliente ha molti ordini), mantiene i dati coerenti e ti permette di rispondere a domande in seguito con SQL. Vedi cos'è Postgres per una panoramica in linguaggio semplice.

Descrivi i tuoi dati prima di costruire

La cosa più utile che puoi fare è scrivere gli elementi che la tua app memorizza e come sono collegati. Non ti servono termini tecnici. Per un'app di prenotazioni:

• Clienti: nome, email, telefono
• Servizi: nome, durata, prezzo
• Prenotazioni: quale cliente, quale servizio, orario di inizio, stato (in attesa, confermata, annullata)

Sono tre tabelle. «Quale cliente» e «quale servizio» diventano collegamenti (chiavi esterne) tra di esse. Farlo bene fin dall'inizio conta molto più di qualsiasi scelta tecnologica, perché cambiare la struttura di dati che contengono già righe reali è più difficile che cambiare il layout di una pagina.

Alcune regole pratiche:

• Una tabella per ogni tipo di elemento. Non infilare gli ordini in una colonna di testo dentro il cliente.
• Dai a ogni riga un ID e una data di creazione. Ti serviranno entrambi più avanti.
• Usa tipi corretti. Le date come date, il denaro come centesimi interi o come tipo decimale, non come testo.
• Segna come obbligatori i campi richiesti. Lascia che sia il database a rifiutare i dati errati, non solo il modulo.

Esempi di prompt

Parti da una funzionalità alla volta, invece di dare tutto lo schema in un colpo solo:

Aggiungi un database a questa app. Crea una tabella delle prenotazioni con nome del cliente, email, servizio, orario di inizio e stato (in attesa, confermata, annullata; predefinito in attesa). Salva nel database le richieste inviate dal modulo di prenotazione, mostra un messaggio di conferma e aggiungi una pagina admin che elenca le prenotazioni dalla più recente.

Poi estendila:

Aggiungi una tabella dei servizi (nome, durata in minuti, prezzo in centesimi). Sostituisci il campo servizio a testo libero nelle prenotazioni con un collegamento ai servizi, e migra le prenotazioni esistenti senza eliminarle.

E rendila più solida:

Assicurati che tutte le letture e scritture nel database avvengano sul server. Il browser non deve ricevere mai la stringa di connessione al database. Valida l'email e l'orario di inizio sul server prima dell'inserimento.

Passo dopo passo

1. Elenca i tuoi dati come sopra: elementi, campi, collegamenti tra di essi.
2. Crea il database. In un app builder AI, chiedilo in chat. Altrove, crea un'istanza Postgres gestita e copia la sua stringa di connessione.
3. Salva la stringa di connessione come segreto (una variabile d'ambiente sul server), mai nel codice. Vedi variabili d'ambiente e segreti.
4. Crea le tabelle. Usa le migrazioni — script versionati che modificano lo schema — così le modifiche sono ripetibili e reversibili.
5. Costruisci le route del server che creano, leggono, aggiornano ed eliminano le righe (CRUD). Il browser chiama queste route; non parla mai direttamente con il database.
6. Collega l'interfaccia a quelle route: moduli che salvano, liste che si caricano, stati vuoti quando non c'è ancora nulla.
7. Verifica la persistenza. Invia qualcosa, ricarica la pagina, aprila in un altro browser. Se i dati non ci sono, non sono stati salvati nel database.
8. Controlla gli accessi. Accedi con un secondo utente e verifica che non puoi vedere né modificare i dati del primo.
9. Pubblica, poi verifica di nuovo sull'URL live, perché l'app pubblicata potrebbe usare una connessione diversa dalla preview.

Errori comuni

• Salvare nel browser pensando che sia salvato. localStorage sembra funzionare finché qualcuno non apre l'app su un altro dispositivo. Verifica sempre in un secondo browser.
• Mettere la stringa di connessione nel codice frontend. Chiunque può leggere il codice frontend. Così ottiene l'intero database.
• Nessun controllo degli accessi. «Mostra i miei ordini» deve filtrare per l'utente connesso sul server, non nell'interfaccia. È la falla di sicurezza più comune nelle app create con l'AI; la nostra checklist di sicurezza la copre.
• Modifiche distruttive dello schema. Chiedere di «rinominare la tabella» o di «cambiare la struttura» può eliminarla e ricrearla. Quando esistono dati reali, scrivi «migra le righe esistenti, non eliminare nulla».
• Salvare file nel database. Immagini e PDF appartengono allo storage dei file, con solo il loro URL o la loro chiave in una tabella. Vedi come aggiungere il caricamento di file.
• Nessun backup. Sappi come la tua piattaforma esegue i backup e come ripristinarli prima di avere clienti.

Checklist

• Ogni tipo di elemento ha una propria tabella con ID e data di creazione
• Campi obbligatori e tipi sono imposti dal database
• La stringa di connessione si trova solo nei segreti lato server
• Tutte le letture e scritture passano dalle route del server
• Ogni utente può leggere e modificare solo le proprie righe
• I dati sopravvivono a un ricaricamento e compaiono in un browser diverso
• Le modifiche allo schema usano migrazioni e conservano le righe esistenti
• Sai come funzionano backup e ripristino
• L'app live è stata verificata dopo la pubblicazione

Aggiungere un database in Mythex

Su Mythex, ogni progetto può ottenere un proprio database Postgres dedicato, sia nel piano Free sia in Pro. Di solito non devi cliccare un pulsante separato di «collega»: chiedilo in chat («salva le email della lista d'attesa in un database») oppure scrivi /database, e i dettagli di connessione vengono inseriti nello spazio di lavoro e nella tua app pubblicata. Le impostazioni del progetto mostrano se un database è attivo.

Il database va in pausa dopo 5 minuti di inattività e si risveglia alla richiesta successiva. L'utilizzo pubblicato viene addebitato per il tempo in cui era effettivamente attivo, con lo stesso saldo di crediti che usi per costruire. Se aggiungi un database dopo aver già pubblicato, pubblica di nuovo così l'app live lo recepisce.

Vedi Database e la ricetta Costruire un'app CRUD nella documentazione. Per il lato login dei dati per utente, leggi come aggiungere il login alla tua app.

Domande