Quando violare le regole del database:JSONB e centesimi

Sapere quando violare le regole del database significa avere un motivo preciso e documentato — e in pratica solo tre motivi reggono a un esame serio. I dati davvero flessibili possono stare in JSONB invece che in tabelle rigide. I contatori troppo costosi da calcolare dal vivo si possono memorizzare. E il denaro si salva sempre in centesimi interi. Tutto il resto resta rigorosamente strutturato.

Ho speso molte parole a predicare la struttura: ogni fatto in un solo posto, tutto collegato tramite riferimenti, niente scorciatoie. Quella regola — la disciplina del 90%+ trattata in normalizzazione del database spiegata semplice — ha costruito una piattaforma in cui centinaia di tabelle restano sincronizzate senza dati duplicati. Questo articolo parla dell'altro lato: il 10%, dove violare le regole non è una scorciatoia ma la decisione ingegneristica corretta.

Quando violare le regole del database: la regola prima delle eccezioni

Prima di tutto, la cornice. Nella mia piattaforma, probabilmente il 95% dei dati è relazionale — tabelle fatte bene, riferimenti fatti bene, struttura fatta bene. Le eccezioni sono appunto eccezioni, ciascuna con un motivo scritto. Questo ordine conta, perché l'AI ti proporrà continuamente di violare le regole, e “è più semplice” non è mai il motivo. Il pericolo non è l'eccezione; è l'eccezione non documentata, che più avanti nessuno riesce a distinguere da un errore.

Detto questo, ecco le tre violazioni che uso di proposito.

Eccezione 1: JSONB per i dati davvero flessibili

PostgreSQL — il motore di database sotto la maggior parte dei SaaS moderni — ha un superpotere chiamato JSONB. Permette a una sola colonna di contenere un intero documento libero: qualsiasi campo, qualsiasi forma, diversa per ogni riga. È la via di fuga del mondo strutturato.

Pensa al tuo database come a uno schedario con cassetti etichettati. JSONB è il cassetto etichettato “varie” — e un cassetto “varie” è davvero utile, purché non diventi il posto dove tieni il passaporto. Il contenuto legittimo: cose la cui forma non puoi conoscere in anticipo. Se i tuoi utenti creano moduli personalizzati, ogni invio ha campi diversi — non puoi progettare in anticipo un cassetto per campi che non esistono ancora. Lo stesso vale per i campi personalizzati definiti dall'utente, le preferenze e le impostazioni di ogni utente, i payload che arrivano dai sistemi di altre aziende, i metadati sciolti e gli snapshot prima/dopo dentro i log di audit.

La regola in una frase che seguo:

Se ti serve collegarlo ad altri dati, interrogarlo spesso o imporre relazioni — rendilo relazionale. Se è flessibile, definito dall'utente o raramente interrogato — JSONB va bene.

Il segnale che JSONB è sicuro: i dati appartengono a una sola riga e non vengono mai interrogati indipendentemente da essa. È esattamente la situazione in cui i problemi di aggiornamento che la struttura serve a prevenire non possono verificarsi. Il segnale che è un errore: ti accorgi di voler fare domande attraverso il JSONB — “tutti i task etichettati come urgenti”, “tutti gli ordini di questo cliente”. Quelle sono relazioni, e le relazioni appartengono alle tabelle.

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

Eccezione 2: i contatori che non puoi permetterti di calcolare dal vivo

La struttura rigorosa dice: non memorizzare mai ciò che puoi calcolare. Il numero di membri di un canale, la valutazione media di un annuncio, il numero di candidature a un'offerta di lavoro — tutto questo si può calcolare su richiesta contando i record sottostanti, e su piccola scala è esattamente ciò che devi fare.

Poi arriva la scala. Una community in cui i canali contengono 100k post non può ricontarli a ogni rendering di pagina. Un marketplace con 500k annunci non può ricalcolare le valutazioni medie dentro ogni risultato di ricerca. Una bacheca di lavoro in cui le aziende ricevono 50k candidature non può contarle dal vivo a ogni visita del profilo. A quel punto memorizzi il numero — una colonna contatore precalcolata — e leggerlo non costa nulla.

Ecco la disciplina che impedisce a tutto questo di marcire: ogni contatore memorizzato ha bisogno di un meccanismo di manutenzione — un trigger o una funzione del database che lo aggiorna nell'istante in cui cambiano i dati sottostanti. Un contatore senza meccanismo non è un'ottimizzazione; è una bugia in attesa di essere creduta. Nel mio schema, ogni singola colonna contatore ha un meccanismo documentato che la tiene sincronizzata, e le note di progettazione registrano quale e quando scatta.

Un affinamento da rubare: i conteggi delle visualizzazioni sono l'eccezione dentro l'eccezione. Si aggiornano in modo asincrono — lanciati dalla pagina dopo il caricamento — anziché con un trigger, così contare le visualizzazioni non rallenta mai una pagina, i bot si possono filtrare e le visite ripetute si possono deduplicare. I contatori esatti (membri, voti, candidature) ottengono i trigger; i contatori di vanità un trattamento più rilassato.

Eccezione 3: il denaro è sempre in centesimi interi

Questa è meno una “violazione di una regola” e più il rifiuto di un default che sembra naturale ed è silenziosamente pericoloso. Salvare 12,99 € come numero decimale 12.99 fa entrare l'aritmetica in virgola mobile del computer nelle tue finanze — e la matematica in virgola mobile produce piccoli errori di arrotondamento che in un grafico sono solo brutti e su una fattura sono inaccettabili.

La soluzione: salva ogni importo monetario come numero intero di centesimi. 12,99 € si salva come 1299. I numeri interi non hanno errori di arrotondamento, mai. L'intero sistema di pagamenti di Stripe parla questa convenzione — importi nella più piccola unità di valuta — quindi il tuo database coincide nativamente con il tuo fornitore di pagamenti. La divisione per 100 avviene solo all'ultimo momento, nel livello di visualizzazione, dove un errore costa un bug estetico invece che denaro.

Nel mio schema questo è assoluto: ogni prezzo, commissione, mancia e totale è in centesimi interi. Nessun decimale per il denaro, da nessuna parte, mai.

La meta-regola: le eccezioni si scrivono

Nota cosa hanno in comune le tre eccezioni. Ognuna ha un innesco ristretto (forma inconoscibile; costo misurato del calcolo dal vivo; la natura del denaro). Ognuna ha un meccanismo compensativo (il test del JOIN; i trigger di sincronizzazione; la conversione nel livello di visualizzazione). E ognuna è documentata — la mia piattaforma tiene un file di decisioni di progettazione che elenca ogni deviazione intenzionale, proprio perché i futuri audit (umani o AI) sappiano distinguere l'ingegneria deliberata dalla sciatteria accumulata.

Questa è la vera differenza tra una violazione professionale delle regole e il debito tecnico: una arriva con un motivo scritto, l'altro con una scrollata di spalle.

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

JSONB è una cattiva pratica?

No — è il JSONB usato male a essere una cattiva pratica. Per dati davvero flessibili e appartenenti a una riga è lo strumento giusto e evita una complessità inutile. Il modo in cui fallisce è usarlo per schivare la progettazione del database: infilare tag, assegnatari o relazioni in un blob JSON perché progettare le tabelle giuste sembrava fatica. Applica il test del JOIN e JSONB resta uno strumento invece di una trappola.

Come capisco quando un contatore va memorizzato?

Quando il conteggio dal vivo fa male in modo misurabile — una pagina che riconta grandi insiemi di record a ogni rendering — e non prima. Comincia calcolando i conteggi su richiesta; memorizza un contatore solo quando è la scala a imporlo, e mai senza il trigger o la funzione che lo mantiene accurato. I contatori prematuri sono complessità immeritata.

Perché non usare semplicemente una colonna decimale per il denaro?

Perché i centesimi interi rendono impossibile, anziché improbabile, un'intera classe di bug finanziari, e perché il tuo fornitore di pagamenti ragiona già in unità minime di valuta. Due rappresentazioni del denaro — centesimi su Stripe, decimali nel tuo database — significano conversioni ovunque, e ogni conversione è un punto in cui sbagliare la fattura di qualcuno.

Cosa succede se uso JSONB per tutto?

Ottieni un database che non sa rispondere alle domande. Niente relazioni, nessuna integrità imposta, nessun filtraggio efficiente, report dolorosi — hai ricostruito un mucchio di documenti con passaggi in più. Flessibilità che non ti serviva, pagata con l'interrogabilità su cui si regge il tuo business. Tieni la struttura per il 95% e spendi JSONB dove la forma è davvero inconoscibile.