Quando la tua app costruita con l’AI ha davvero bisogno di un database (e quando no)

Cosa fa davvero un database?

Il compito di un database è garantire che due persone non possano sovrascrivere o distruggere per errore il lavoro l’una dell’altra usando la stessa app — velocità, struttura e ricerche complesse sono solo effetti collaterali della soluzione a questo unico problema.

Hai costruito la tua app con l’AI. Funziona. Salva i dati su file o su un foglio di calcolo. Sembra tutto a posto.

Poi succede una di queste due cose:

La tua app diventa più lenta ogni volta che qualcuno la usa.
Due utenti provano a usarla contemporaneamente e qualcosa si rompe.

Nessuno di questi due problemi è evidente finché non è troppo tardi. Sono entrambi problemi di database travestiti da altro.

Se stai ancora usando file o fogli di calcolo, probabilmente non hai ancora bisogno di un database. Ed è del tutto normale. Ma dovresti conoscere i segnali che ti dicono che presto ne avrai bisogno.

Quando va bene usare solo file invece di un database?

I file vanno benissimo finché sei l’unica persona a usare l’app e le modifiche sono rare — questo è l’unico vero test.

Il sito portfolio di un freelance? I file sono perfetti. Un tracker personale delle spese? I file vanno bene. Un progetto hobbistico con un solo utente? Non complicarti la vita.

Veri segnali che i file stanno funzionando:

Solo una persona usa l’app alla volta (o gli utenti sono offline mentre altri lavorano).
Aggiorni i dati raramente (una volta al giorno, una volta a settimana, una volta al mese).
Perdere gli ultimi 30 secondi di lavoro è accettabile (il tuo builder può semplicemente riprovare).
Il file dei dati è abbastanza piccolo da poter essere inviato via email (sotto i 10 MB).

Se tutti e quattro i punti sono veri, resta sui file. Sul serio. La semplicità è una qualità, non un limite.

Perché la mia app costruita con l’AI sta diventando più lenta?

La tua app rallenta perché il file su cui salva continua a crescere, e il tuo builder carica l’intero file in memoria ogni volta che deve modificare qualcosa — un costo che all’inizio è quasi impercettibile e diventa doloroso man mano che il file cresce.

Lo noti come una sensazione. La tua app sembra più lenta di prima. Cliccare un pulsante richiede un secondo in più. Le ricerche sono visibilmente più lente. Non hai cambiato il codice — perché è più lenta? Ecco lo schema:

L’app carica l’intero file di dati (100 righe, veloce).
Un utente aggiunge un record (ora 101 righe).
L’app rilegge l’intero file per ricontrollare (ancora veloce).
Dopo 2.000 record, leggere il file richiede 2 secondi.
Dopo 10.000 record, ne richiede 20.

Non è esponenziale, ma diventa evidente intorno ai 5.000 record e diventa doloroso intorno ai 20.000.

Prima soluzione (prima di aggiungere un database): chiedi al tuo builder di caricare i dati su richiesta. Carica solo i record che stai mostrando, o solo le colonne che stai visualizzando. Molte app possono restare sui file semplicemente essendo più intelligenti su cosa caricano.

Quando passare a un database: hai più di 50.000 record di dati, oppure la lentezza persiste anche dopo aver ottimizzato i caricamenti.

Perché la mia app ha perso dati quando due persone la usavano contemporaneamente?

Succede perché due persone possono modificare lo stesso file contemporaneamente e l’app non ha modo di saperlo — chi salva per secondo vince, e le modifiche della prima persona spariscono in silenzio. Si chiama “scrittura in conflitto” ed è un classico bug di perdita dati.

Entrambe le persone vedono le proprie modifiche sullo schermo. Entrambe cliccano “salva”. Capirai che sta succedendo se:

Gli utenti segnalano ogni tanto dati mancanti (specialmente se più persone sono nell’app nello stesso momento).
Gli utenti segnalano di vedere le modifiche di altre persone “annullate” senza spiegazione.
Due utenti modificano lo stesso record e le modifiche di uno dei due svaniscono.
Ricevi messaggi tipo “giuro che l’avevo aggiunto ieri e ora non c’è più.”

Non è colpa dell’app. È un limite intrinseco di come funzionano i file. Non c’è un buon modo per gestire questo problema senza un database.

Quando passare a un database: non appena due persone iniziano a usare l’app contemporaneamente, anche se non ha ancora dato problemi.

Perché la mia app non riesce a gestire ricerche complesse con i file?

Perché con i file il tuo builder deve caricare e filtrare a mano ogni dataset collegato, un passo alla volta, invece di fare una domanda e ottenere una risposta — un database fa lo stesso lavoro in millisecondi con un’unica query.

Diciamo che vuoi trovare “tutte le fatture non pagate dei clienti in California che non sono stati contattati nell’ultima settimana.” Con i file, il tuo builder deve:

Caricare tutte le fatture.
Filtrare per non pagato = true.
Caricare tutti i clienti e abbinarli per ID.
Filtrare per stato = “CA”.
Caricare tutti i contatti e abbinarli per ID cliente.
Filtrare per data > una settimana fa.

Con un database, scrivi una query e fa tutto questo in millisecondi.

Quando passare a un database: quando il tuo builder dice “per rispondere a questa domanda dovrei scrivere codice personalizzato.” O quando noti che l’app fa un sacco di lavoro solo per mostrarti dati filtrati.

Cosa devo dire al mio builder quando ho bisogno di un database?

Digli chiaramente cosa non va e chiedigli un piano — qualcosa come: “L’app sta diventando [più lenta/ha perso dei dati/ha bisogno di ricerche più complesse]. Penso che dovremmo aggiungere un database. Quanto è grande questo cambiamento?”

La maggior parte dei builder può far passare un’app dai file a un database in 1-2 giorni per app piccole, qualche giorno in più per quelle più grandi. Il processo è:

Mantenere l’app perlopiù invariata (gli utenti non vedranno un grande cambiamento).
Collegare un backend con database (dal punto di vista del resto del codice sembra ancora fatto di file, ma sotto c’è un database).
Testarlo a fondo (perché spostare dati è un’operazione delicata).
Far girare entrambi i sistemi in parallelo per una settimana finché non sei sicuro.

Il builder potrebbe chiederti:

“Dovremmo usare PostgreSQL, MySQL, o qualcos’altro?”
- La tua risposta: “Quello con cui ti trovi più a tuo agio. Io non conosco la differenza, ma mi fido di te.”
“Ci vorranno 3 giorni. Ne vale la pena?”
- La tua risposta: “Se dobbiamo comunque spostarci, prima è meglio che dopo, quando i dati saranno di più.”
“Dovremmo migrare i vecchi dati?”
- La tua risposta: “Sì, a meno che non siano meno di 100 record, in quel caso va bene ripartire da zero.”

Devo capire i database io stesso?

No — non hai bisogno di sapere cos’è un database, imparare SQL, o valutare PostgreSQL contro MySQL. Tutto quello che devi dire al tuo builder è: “Due persone devono poter usare l’app nello stesso momento senza perdere il lavoro l’una dell’altra.”

Tutto qui. Il tuo builder può scegliere il database. Uno semplice come SQLite (per un’app personale o di team con meno di 10 utenti simultanei) o PostgreSQL (per qualsiasi cosa più grande) fanno entrambi il loro lavoro.

Come faccio a sapere se la mia app ha bisogno di un database?

Spunta quali di questi quattro punti valgono per te — due o più caselle spuntate significa che è ora di aggiungere un database, subito.

Lentezza: l’app sembrava più veloce 3 mesi fa, ora sembra più lenta. Il file dei dati supera i 20 MB o ha più di 10.000 record.
Perdita di dati: le modifiche di qualcuno sono sparite, o più utenti hanno segnalato modifiche mancanti.
Complessità: vuoi fare domande tipo “mostrami X filtrato per Y” e il builder dice “è difficile da fare con i file.”
Utenti: più di una persona usa l’app nello stesso momento (anche solo occasionalmente).

Se hai spuntato due o più caselle, la tua app è pronta per un database.

Se non hai spuntato nessuna casella, i tuoi file vanno bene. Tienili così. La semplicità ha valore.

Se hai spuntato una casella, chiedi al tuo builder: “È abbastanza veloce da poterci convivere per altri 6 mesi?” Se sì, aspetta. Se no, agisci subito.