Cos'è un database:spiegato ai founder non tecnici

Cos'è un database? Lo capisci già, solo che non lo sai ancora. Un database è un foglio di calcolo con superpoteri: le stesse righe e colonne che usi in Google Sheets, ma capace di servire migliaia di utenti contemporaneamente, far rispettare regole in automatico e rispondere a domande su miliardi di record all'istante. Per un fondatore SaaS è il livello più importante del prodotto.

Nel modello del ristorante su come funziona un SaaS, il database è il ricettario e la dispensa: l'unico posto in cui qualcosa viene ricordato. Ecco tutto ciò che devi capire, partendo dal foglio di calcolo che già conosci.

Cos'è un database: fogli di calcolo e database, cosa cambia davvero

Immagina di tracciare i clienti in Google Sheets: una riga per cliente, colonne per nome, email, piano e data di iscrizione. Quel foglio è essenzialmente una tabella di database. Allora perché non far girare il tuo SaaS su un foglio di calcolo?

In parole povere: un foglio di calcolo è un blocco note. Un database è l'archivio di un ufficio pubblico: organizzato, consultabile, permanente e costruito per crescere.

Tabelle, righe e colonne: il vocabolario

Tre parole coprono la maggior parte delle conversazioni sui database che avrai mai:

Una tabella è come una scheda di un foglio di calcolo, e contiene un solo tipo di cosa. Il tuo prodotto potrebbe avere una tabella users per le persone che si iscrivono, una tabella products, una tabella orders, una tabella payments. Una tabella per tipo di entità: questa è la regola.

Una riga è una singola istanza di quella cosa. Nella tabella degli utenti, ogni riga è un utente. Gli sviluppatori chiamano le righe "record".

Una colonna è un'informazione sulla cosa: l'email, la data di iscrizione, il piano. Ogni colonna dichiara che tipo di dato contiene: testo, numeri interi, decimali, valori vero/falso, date, identificativi univoci. È così che il database fa rispettare le regole in automatico: si rifiuta semplicemente di memorizzare la parola "ciao" in una colonna numerica. Il tuo foglio di calcolo la accetterebbe volentieri e romperebbe in silenzio i tuoi report.

Le chiavi: come le tabelle si collegano tra loro

Qui i database diventano davvero potenti, ed è dove finisce l'analogia con il foglio di calcolo.

Ogni tabella ha una chiave primaria: una colonna, di solito chiamata id, che identifica in modo univoco ogni riga. Deve essere univoca, mai vuota e mai cambiare. Pensala come l'impronta digitale di ogni record.

Una chiave esterna è una colonna di una tabella che punta alla chiave primaria di un'altra. La tua tabella degli ordini non ripete nome ed email del cliente su ogni ordine: memorizza solo uno user_id che rimanda alla tabella degli utenti. Quel puntatore crea una relazione: un utente, molti ordini. Ora puoi chiedere "mostrami ogni ordine che questo cliente ha mai effettuato" e il database segue il collegamento all'istante.

Le relazioni sono il motivo per cui non copi i dati in giro. Se l'email di un cliente stesse su ogni riga di ordine, cambiarla significherebbe aggiornare ogni ordine, e le copie finirebbero inevitabilmente fuori sincrono. Memorizza ogni fatto una volta sola, collegalo con le chiavi, e la verità resta in un posto solo.

L'unica regola di progettazione: la struttura decide cosa può fare il tuo prodotto

Ecco l'intuizione da fondatore. Considera due modi di memorizzare gli abbonamenti. Il modo sbagliato infila tutto in una colonna di testo sulla riga dell'utente: "Piano Pro, scade il 15-01-2025, pagato 99 €". Sembra a posto, finché non fai una domanda. Quanti utenti Pro abbiamo? Chi deve rinnovare il mese prossimo? Qual è il prezzo medio dell'abbonamento? Non puoi rispondere a nessuna, perché i fatti sono intrappolati in un blocco di testo.

Il modo giusto mette gli abbonamenti in una tabella a parte: piano, prezzo e data di scadenza ciascuno in una propria colonna tipizzata, collegata all'utente da una chiave esterna. Stessa informazione. Ora puoi interrogare qualsiasi cosa.

Questo è lo schema in miniatura: la struttura dei tuoi dati determina le capacità del tuo prodotto. Ecco perché il metodo di lavoro per i fondatori dell'era AI è progettare prima il database e lasciare che tutto il resto ne segua.

12 settimaneLa carriera aziendale non è mai stata il pianoCandidati al Solopreneur Accelerator.Candidati ora →

I tuoi dati sopravvivono al tuo codice

La realtà della costruzione di un prodotto: riscriverai il frontend tre volte e la logica del backend evolverà di continuo, ma lo schema del tuo database è per sempre. Facebook ha ancora dati del 2004; il suo frontend è cambiato cento volte, mentre le tabelle centrali di utenti e post restano simili.

Per questo i cambiamenti al database fanno male in un modo in cui i cambiamenti al codice non fanno. Aggiungere una colonna è facile. Cambiare il tipo di una colonna quando contiene già dati reali dei clienti è difficile: ogni record esistente va convertito e il codice esistente può rompersi. Rimuovere una colonna con dei dati dentro è spaventoso, perché quei dati spariscono per sempre. Pensaci bene prima di creare lo schema; cambiarlo dopo è la parte costosa.

E questo, più di ogni altra cosa, è l'argomento contro il chiedere all'AI di "costruirlo e basta" senza un modello dei dati. Il codice scritto male dall'AI si rigenera in pochi minuti. Una struttura dati cresciuta per caso, il fallimento tipico della trappola del vibe coding, ti segue per tutta la vita del prodotto.

Due cose che il database fa in particolare per un SaaS

Tiene separati i dati dei tuoi clienti. Un SaaS serve molte aziende da una sola applicazione, quindi ogni tabella porta un identificativo del tenant e il database stesso fa rispettare che l'Azienda A non possa mai vedere le righe dell'Azienda B: come un condominio, con infrastruttura condivisa e spazi privati separati. Quel meccanismo si chiama row-level security e merita una spiegazione tutta sua.

Ricorda in modo responsabile. I prodotti ben progettati raramente cancellano davvero qualcosa: segnano i record come eliminati, così gli errori si possono annullare e la storia sopravvive. Ogni tabella registra quando ogni riga è stata creata e aggiornata l'ultima volta. Queste piccole abitudini fanno la differenza tra un prodotto che puoi debuggare e verificare e uno che ti risponde con una scrollata di spalle.

La buona notizia: nulla di tutto questo lo costruisci a mano. Gli strumenti moderni ti danno un database di livello professionale con autenticazione e sicurezza integrate: è una voce di costo nel costo reale di costruire un SaaS, non una decisione di assunzione. Il tuo compito è la parte che gli strumenti non sanno fare: decidere quali sono le tabelle.

Il libroThe Solopreneur RevolutionLuis Gonçalves su come costruire un'attività da solopreneur con l'IA mentre sei ancora dipendente.Scopri il libro →

Domande frequenti

Che cos'è un database, in parole semplici?

Un archivio strutturato e permanente per i dati del tuo prodotto: come un foglio di calcolo, ma capace di servire migliaia di utenti contemporaneamente, far rispettare regole in automatico e rispondere a domande su miliardi di righe all'istante. Tutto ciò che il tuo SaaS deve ricordare vive lì.

Perché non posso far girare il mio SaaS su un foglio di calcolo?

I fogli di calcolo arrivano al massimo a circa un milione di righe, ammettono un solo editor alla volta e non applicano nulla: refusi, duplicati e incoerenze si insinuano in silenzio. Un database è automatizzato, validato e costruito per l'accesso concorrente. I fogli di calcolo servono per l'analisi; i database servono per i prodotti.

Devo progettare io il database se non sono un fondatore tecnico?

Tu decidi la struttura; l'AI scrive l'implementazione. Elenca le "cose" del tuo prodotto (utenti, progetti, ordini), decidi cosa ti serve sapere di ciascuna e come si relazionano. È un esercizio di pensiero sul tuo business, non di programmazione, ed è l'unica decisione costosa da cambiare in seguito.

Che cosa sono le chiavi primarie e le chiavi esterne?

Una chiave primaria identifica in modo univoco ogni riga di una tabella, l'impronta digitale di ogni record. Una chiave esterna è una colonna che punta alla chiave primaria di un'altra tabella, creando relazioni come "un utente ha molti ordini". Le chiavi sono il modo in cui un database collega i fatti senza copiarli.