Tipi di dati MySQL spiegati: scegli i tipi di colonna giusti per prestazioni e scalabilità

1. Introduzione: Perché dovresti comprendere l’elenco dei tipi di dato MySQL

Quando progetti tabelle o integri applicazioni con MySQL, una delle domande più comuni è: “Quale tipo di dato dovrei usare per questa colonna?”
Deve essere INT? Hai davvero bisogno di BIGINT? VARCHAR è sufficiente per le stringhe, o è meglio TEXT? Queste scelte possono sembrare minori, ma costituiscono la base che influenzerà il tuo sistema in seguito.

Se sottovaluti come scegliere i tipi di dato, spesso ti imbatterai in problemi come i seguenti:

• Man mano che i dati crescono oltre le previsioni, sprechi spazio di archiviazione
• Gli indici si gonfiano e le prestazioni delle query si degradano gradualmente
• Valori fuori intervallo o overflow causano bug o eccezioni inaspettate
• Sei costretto a cambiare i tipi di colonna in seguito, innescando una migrazione su larga scala

In altre parole, comprendere sistematicamente i tipi di dato MySQL e scegliere quello giusto per ogni caso d’uso è il modo più veloce per migliorare sia le prestazioni sia la manutenibilità.

Questa pagina è principalmente destinata a lettori come:

• Ingegneri che stanno per avviare uno sviluppo serio di sistemi con MySQL
• Ingegneri backend / infrastruttura che vogliono rivedere i design delle tabelle esistenti
• Sviluppatori web e programmatori che cercano “tipi consigliati” in base al caso d’uso

Inizieremo organizzando i principali tipi di dato MySQL in un “elenco” categorizzato. Poi spiegheremo i tipi chiave—numerici, stringa, data/ora, JSON, ENUM/SET—coprendo le loro caratteristiche, i casi d’uso tipici e i consigli di selezione. Infine, riassumeremo gli errori di design più comuni e come evitarli, insieme a una FAQ.

Non si tratta solo di un “elenco di termini”. È strutturato come guida decisionale in modo che tu non rimanga bloccato quando progetti tabelle in progetti reali. Nella sezione successiva, immergiamoci su come pensare ai tipi di dato e rivedere l’elenco categorizzato.

2. Cos’è un tipo di dato e perché “scegliere il tipo giusto” è importante?

In un database, un “tipo di dato” è una regola che definisce che tipo di valori una colonna può memorizzare.
MySQL fornisce molti tipi di dato—interi, decimali, stringhe, date, binari, JSON e altro—perciò devi scegliere in modo appropriato a seconda del tuo scopo.

Il ruolo dei tipi di dato

Un tipo di dato non è solo una “categoria di formato”. Svolge più ruoli contemporaneamente:

• Restringe il tipo di dati (numerico vs. stringa, booleano, ecc.)
• Definisce l’intervallo consentito e il numero di cifre
• Determina la memoria richiesta (dimensione di archiviazione)
• Influenza le strutture degli indici e le prestazioni di ricerca
• Influisce sulle conversioni implicite e sulle regole di confronto (ad es., collazione delle stringhe)

In breve, i tipi di dato non sono semplicemente “contenitori”—sono scelte di design fondamentali che influenzano l’intero ciclo di vita della gestione dei dati.

Cosa succede se scegli il tipo sbagliato?

Se scegli il tipo di dato sbagliato, problemi come questi si verificano frequentemente nel lavoro reale:

• Spreco di spazio di archiviazione

Ad esempio, se BIGINT (8 byte) è sufficiente ma usi per errore DECIMAL o LONGTEXT, potresti consumare molto più spazio su disco del previsto.

• Query più lente

Se usi eccessivamente ricerche LIKE su colonne TEXT enormi, o se gli indici si gonfiano perché hai scelto tipi numerici eccessivamente grandi, l’esecuzione di SQL tende a rallentare.

• Valori incoerenti o overflow

Potresti memorizzare valori che non entrano in INT, causando valori negativi inaspettati, arrotondamenti o altri problemi.

• Modifiche di tabella costose

Specialmente su tabelle grandi, cambiare i tipi con ALTER TABLE può portare a:

• Lunghi tempi di blocco
• Impatto sul servizio
• Lavori di migrazione dei dati e altri rischi.

Categorie chiave da comprendere fin da subito

I tipi di dato MySQL sono ampiamente categorizzati come segue:

• Tipi numerici (interi, decimali)
• Tipi stringa
• Tipi data e ora
• Tipi binari
• Tipo JSON
• Tipi ENUM / SET
• Tipi di dati spaziali

Ogni categoria ha diversi compromessi—punti di forza/debolezze, “leggero vs. pesante” e “facile vs. difficile da cercare”. Ecco perché è necessario la selezione ottimale del tipo per ogni caso d’uso.

3. Categorie di Tipi di Dati MySQL (Elenco di Panoramica)

In questa sezione, riassumeremo i tipi di dati disponibili in MySQL come una lista di panoramica categorizzata. In pratica, le prime cose che vuoi confermare sono “Quali tipi esistono?” e “Quale dovrei usare?”.
Quindi qui mostreremo chiaramente casi d’uso, caratteristiche chiave e nomi rappresentativi dei tipi, per poi spiegare ogni categoria in maggiore dettaglio nelle sezioni successive.

3.1 Tipi Numerici

I tipi numerici sono la base per tutti i processi numerici, inclusi interi, decimali e valori a virgola mobile.
Questa categoria è usata più frequentemente per ID, quantità, prezzi, controlli di flag e molti altri scopi.

Tipi Interi

Note

• Aggiungere UNSIGNED raddoppia l’intervallo positivo.
• INT è usato in molti casi, ma usare BIGINT casualmente può appesantire gli indici.

Tipi Decimale / Virgola Mobile

Note

• Per il denaro, DECIMAL è l’unica scelta ragionevole. I tipi a virgola mobile (FLOAT / DOUBLE) possono introdurre errori.
• In casi che coinvolgono molti calcoli, DOUBLE è talvolta scelto per i compromessi tra velocità e precisione.

Altri Tipi Numerici

3.2 Tipi Data e Ora

La gestione di data/ora è usata molto frequentemente nello sviluppo di applicazioni.
A seconda dello scopo, fattori come “comportamento del fuso orario”, “aggiornamenti automatici” e “precisione a livello di secondi” differiscono, quindi scegliere il tipo giusto è importante.

Note

• Se vuoi gestire automaticamente “updated at”, TIMESTAMP è comodo.
• Per “log” o “storico” dove vuoi memorizzare timestamp accurati, DATETIME è comunemente usato.

3.3 Tipi Stringa / Binari

Nomi utente, email, password, descrizioni—le stringhe sono spesso l’area più complessa nella progettazione delle tabelle.

Stringhe a Lunghezza Fissa

Stringhe a Lunghezza Variabile

Testo Grande (Famiglia TEXT)

Note

• Usa TEXT quando devi memorizzare stringhe molto grandi come corpi di articoli o descrizioni lunghe.
• Fai attenzione alla ricerca e alla progettazione degli indici.

Dati Binari (BINARY / BLOB)

※ In generale, i file di grandi dimensioni non vengono memorizzati nel database; un design comune è quello di archiviarli in storage esterno.

Tipi ENUM / SET (Enumerazioni)

Note

• Se devi modificare la definizione del tipo in seguito, la manutenzione diventa pesante.
• Può essere efficace per candidati di piccola scala e statici.

3.4 Tipo JSON

• Ottieni la flessibilità simile a NoSQL pur potendo utilizzare le funzioni specifiche per JSON.
• Tuttavia, non è consigliato inserire dati frequentemente ricercati in JSON. Se può essere normalizzato, dovrebbe essere modellato come tabelle strutturate.

3.5 Tipi Spaziali

Questi sono usati quando si lavora con dati geografici e di localizzazione.

Nelle tipiche applicazioni web, questi non sono usati spesso, ma sono importanti per le app di mappe e le integrazioni GPS.

4. Come Scegliere e Usare Ogni Tipo di Dato (Punti Chiave di Decisione)

In questa sezione approfondiamo le categorie introdotte sopra, concentrandoci su “come scegliere in scenari reali”.
Conoscere solo i nomi non è sufficiente—selezionare il tipo di dato più adatto ha un impatto notevole sulla manutenibilità, le prestazioni e la scalabilità futura.

4.1 Come Scegliere i Tipi Numerici

Criteri per Scegliere i Tipi Interi

Quando si selezionano i tipi interi, concentrati su questi tre punti:

1. Comprendere l’Intervallo Massimo Richiesto

• Contatori piccoli → TINYINT
• Quantità di prodotto / flag → SMALLINT / INT
• ID su larga scala o log → BIGINT

Alcuni progetti abusano di BIGINT per le chiavi primarie, ma questo può facilmente portare a indici più grandi e influire negativamente sulle prestazioni.

2. Considerare Attivamente UNSIGNED

If you only handle positive values (e.g., numeric IDs, inventory counts)
→ using UNSIGNED doubles the range and may allow you to use a smaller type.

3. Per valori monetari o di precisione critica, usa DECIMAL

Per valori in cui “gli errori non sono accettabili”, evita FLOAT/DOUBLE e usa sempre DECIMAL.

4.2 Come scegliere i tipi di data e ora

Il tipo appropriato dipende dal tuo caso d’uso.

Differenze tra DATETIME e TIMESTAMP

Regole generali per la scelta

• Log di applicazione o registri di eventi → DATETIME (evita gli effetti di conversione del fuso orario)
• Quando vuoi registrare automaticamente i timestamp di aggiornamento → TIMESTAMP (comportamento di auto‑aggiornamento conveniente)

Dove YEAR è utile

• Categorie di anno fiscale, anni di rilascio, anni di fondazione, ecc. → Gestisci in modo compatto (1 byte)

4.3 Come scegliere i tipi di stringa

Come decidere tra CHAR e VARCHAR

Quando dovresti usare CHAR

• La lunghezza è sempre costante: codici di prefettura, codici di paese, identificatori a lunghezza fissa, ecc.
• Dati che necessitano di accesso rapido e sono aggiornati raramente

Quando dovresti usare VARCHAR

• La lunghezza varia: nomi, indirizzi email, titoli, ecc.
• La scelta predefinita migliore nella maggior parte delle situazioni

Dovresti usare TEXT?

Vantaggi di TEXT

• Supporta testo di grandi dimensioni (descrizioni, corpi di articoli, ecc.)

Attenzioni per TEXT

• L’indicizzazione è limitata (sono richiesti indici prefisso)
• Le prestazioni possono degradare quando usato in JOIN o clausole WHERE
• La ricerca e l’ordinamento possono essere onerosi

Raccomandazione:
Usa TEXT per “stringhe grandi” come corpi o note,
e usa VARCHAR il più possibile per tutto il resto.

4.4 Come scegliere il tipo JSON

Il tipo JSON è molto utile, ma devi usarlo “correttamente”.

Quando JSON funziona bene

• Impostazioni flessibili o dati con un numero variabile di campi
• Casi d’uso di ricerca limitata, o quando l’applicazione lo espande/analizza
• Memorizzare dati leggeri che non richiedono una tabella master

Quando JSON è inadatto

• Dati che cerchi frequentemente
• Dati usati per ricerche filtrate, aggregazioni o JOIN
• Dati strutturati che dovrebbero essere normalizzati

Regola pratica:
I dati che devi cercare dovrebbero essere normalizzati e trattati come struttura.
Non dimenticare che JSON è “flessibile ma debole per la ricerca”.

4.5 Come scegliere i tipi ENUM / SET

Quando ENUM è appropriato

• Gli stati sono fissi: ad esempio, status (draft / published / archived)
• Un piccolo insieme di opzioni che cambiano raramente

Attenzioni per ENUM

• Aggiungere o modificare valori richiede ALTER TABLE
• Rischio di perdere coerenza con le definizioni lato applicazione

Quando SET è appropriato

• Dati di piccola scala che richiedono selezione multipla (ad esempio, giorni della settimana disponibili, o quando ci sono solo poche opzioni di tag)

Attenzioni per SET

• Le combinazioni di valori possono diventare complesse
• Gestire stati a valori multipli può diventare difficile

4.6 Come scegliere i tipi Binary / BLOB

BINARY / VARBINARY

• Token, ID, valori hash, ecc.
• Binario a lunghezza fissa (ad esempio, UUID da 16 byte)

Casi d’uso tipici per i tipi BLOB

• File piccoli, immagini thumbnail, dati crittografati

Ma nota

• Memorizzare file di grandi dimensioni nel database rende i backup più pesanti
• Il carico di lettura/scrittura aumenta anche → Nei sistemi reali, è consigliato l’archiviazione esterna + gestione dei percorsi

5. Pratica: Come usare la “Lista di riferimento dei tipi di dati” quando si progettano tabelle

In questa sezione, spiegheremo come usare la lista dei tipi di dati MySQL in un flusso di lavoro pratico quando si progettano tabelle.
Piuttosto che memorizzare solo i tipi, organizzare “perché scegli quel tipo” attraverso logica e passaggi porta a una progettazione di database di qualità superiore.

5.1 Passo 1: Chiarire lo “scopo” e la “natura” della colonna

Prima, definisci chiaramente cosa sarà memorizzato nella colonna.

Checklist

• È numerico, stringa, data o un flag?
• È di lunghezza variabile o a lunghezza fissa?
• Qual è il valore massimo o la lunghezza massima?
• Deve essere consentito NULL?
• È probabile che cresca in futuro?

Se procedi con assunzioni vaghe qui, la scelta del tipo diventa inutilmente complicata in seguito.

5.2 Passo 2: Stimare l’Intervallo e il Formato Richiesti

Successivamente, stima i limiti superiori/inferiori, la lunghezza dei caratteri e la precisione richiesta dei valori che memorizzerai.

Esempio: Colonna ID

• Il conteggio massimo dei record arriverà a decine di milioni? Centinaia di milioni? → Questo ti aiuta a determinare se INT è sufficiente o se è necessario BIGINT.

Esempio: Nome Prodotto

• Media di 15–25 caratteri, massimo circa 50? → VARCHAR(50) è sufficiente. TEXT è superfluo.

Esempio: Prezzo

• È necessaria precisione? → Dovresti scegliere qualcosa come DECIMAL(10,2).

5.3 Passo 3: Considerare il Volume dei Dati e le Prestazioni

Scegliere i tipi di dati MySQL influisce direttamente sulle prestazioni.

Considerazioni Chiave

• Tipi troppo grandi → consumano spazio di archiviazione e rendono gli indici più pesanti
• TEXT / BLOB → degradano le prestazioni di ricerca
• JSON → flessibile ma debole per la ricerca
• TIMESTAMP → efficiente per aggiornamenti automatici e confronti

In particolare, le colonne indicizzate dovrebbero utilizzare il tipo di dato più leggero possibile.

5.4 Passo 4: Convalidare i Tipi con Dati di Esempio

Dopo aver progettato la tabella, inserisci decine o centinaia di righe di dati di test e verifica il comportamento.

Cosa Controllare

• Ci sono problemi di arrotondamento o troncamento non intenzionali?
• VARCHAR è sufficiente, o dovrebbe essere TEXT ?
• L’ordinamento e la ricerca delle date/ore si comportano come previsto?
• Prestazioni di lettura/scrittura JSON

Testare con dati realistici riduce i “errori teorici”.

5.5 Passo 5: Considerare Scalabilità e Manutenibilità

Nella fase finale della progettazione della tabella, verifica se le modifiche future saranno facili.

Esempi di Cambiamenti di Tipo Significativi

• ENUM (richiede ALTER TABLE quando si aggiungono valori)
• TEXT → VARCHAR (l’espansione è facile, la riduzione è rischiosa)
• FLOAT → DECIMAL (può cambiare la semantica)

Scegli i tipi valutando se è probabile un’espansione futura.

5.6 Passo 6: Esempio CREATE TABLE (Esempio Pratico)

Di seguito è riportata una tabella di esempio che riflette gli standard comuni di selezione dei tipi di dati in una tipica applicazione web.

CREATE TABLE products (
    id           BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    name         VARCHAR(100) NOT NULL,
    price        DECIMAL(10,2) NOT NULL,
    stock        INT UNSIGNED NOT NULL DEFAULT 0,
    status       ENUM('draft', 'published', 'archived') NOT NULL DEFAULT 'draft',
    description  TEXT,
    created_at   DATETIME NOT NULL,
    updated_at   TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

Punti Chiave in Questo Esempio

• id : Usa BIGINT UNSIGNED considerando la scala futura
• name : Stringa variabile di media lunghezza → VARCHAR
• price : Valore monetario → DECIMAL preciso
• stock : Conteggio dell’inventario → INT UNSIGNED
• status : Insieme fisso di valori → ENUM
• description : Testo potenzialmente lungo → TEXT
• updated_at : TIMESTAMP auto-aggiornante conveniente

Come mostrato, ogni scelta di tipo dovrebbe avere una motivazione chiara, e saper articolare tale ragionamento è un segno distintivo di un buon design.

6. Errori Comuni e Come Evitarli

Poiché MySQL offre molti tipi di dati, diversi errori comuni compaiono frequentemente nei progetti reali. Questa sezione evidenzia le insidie tipiche e fornisce contromisure pratiche.

6.1 Utilizzare Tipi di Dati Eccessivamente Grandi

Esempi Comuni

• Usare BIGINT per tutti gli ID
• Impostare ogni stringa a VARCHAR(255)
• Usare TEXT per contenuti non testuali

Problemi

• Spazio di archiviazione sprecato
• Indici gonfi che compromettono le prestazioni delle query
• Larghezza di banda di rete sprecata (trasferimenti di dati più grandi)

Come Evitare

• Stima in anticipo i valori massimi e minimi
• Imposta le lunghezze di VARCHAR basandoti su evidenze
• Usa TEXT solo quando è davvero necessario

6.2 Uso di FLOAT/DOUBLE per valori decimali (Problemi di precisione)

Esempi comuni

• Memorizzare i prezzi come FLOAT
• I confronti numerici falliscono a causa di errori di arrotondamento

Come evitare

• Usa DECIMAL per denaro e valori critici di precisione
• Evita FLOAT / DOUBLE salvo per calcoli scientifici o temporanei

6.3 Colonne VARCHAR sovradimensionate

Esempi comuni

• Usare VARCHAR(255) come valore predefinito
• Impostare lunghezze grandi per colonne che memorizzano solo circa 30 caratteri

Problemi

• Memoria e spazio di archiviazione sprecati
• Gli indici spesso diventano più pesanti

Come evitare

• Stima le lunghezze medie e massime dai dati reali
• Evita dimensioni inutilmente grandi (es. indirizzi email → VARCHAR(100) )

6.4 Uso eccessivo dei tipi TEXT

Esempi comuni

• Supporre che “stringa = TEXT”
• Usare TEXT per dati che necessitano di filtraggio o ricerca

Problemi

• Molte limitazioni di indicizzazione
• Ricerche LIKE pesanti
• Elaborazione più lenta nei JOIN

Come evitare

• Usa TEXT solo per contenuti lunghi come descrizioni o corpi di testo
• Memorizza le stringhe ricercabili in VARCHAR quando possibile

6.5 Scegliere i tipi Date/Time senza comprenderne le proprietà

Esempi comuni

• Usare DATETIME per tutto
• Usare DATETIME per “updated at”, così non si auto‑aggiorna
• I timestamp cambiano a causa delle differenze di fuso orario

Come evitare

• Necessità di auto‑aggiornamento: TIMESTAMP
• Vuoi evitare spostamenti di fuso orario: DATETIME
• Hai bisogno solo dell’anno: YEAR

6.6 Uso troppo informale di ENUM / SET

Esempi comuni

• Usare ENUM anche se le opzioni potrebbero cambiare in futuro
• Usare SET come una lista separata da virgole

Problemi

• Le modifiche richiedono ALTER TABLE
• È più probabile un’incoerenza con le definizioni lato applicazione

Come evitare

• Se i valori possono aumentare, gestiscili in una tabella master separata
• Usa ENUM solo quando l’insieme è piccolo e realmente fisso

6.7 Inserire troppo in JSON “perché è comodo”

Esempi comuni

• Inserire strutture che dovrebbero essere normalizzate in JSON
• Memorizzare dati frequentemente ricercati all’interno di JSON

Problemi

• Le prestazioni di ricerca peggiorano
• Gli indici sono meno efficaci / più difficili da usare
• Maggior lavoro di parsing lato applicazione
• Il design senza schema rende più facile rompere la coerenza

Come evitare

• Usa JSON solo per dati che non cerchi
• Limitalo a “dati piccoli e variabili” come le impostazioni
• Normalizza le informazioni usate per JOIN e ricerca

6.8 Sottovalutare il costo dei cambiamenti di tipo

Problemi

• ALTER TABLE può essere estremamente pesante su tabelle grandi
• Potrebbero verificarsi tempi di inattività del servizio o lunghi blocchi
• In alcuni casi è richiesta la migrazione dei dati

Come evitare

• Pianifica la crescita futura durante la fase di progettazione
• Usa ENUM con attenzione
• Lascia spazio nella precisione/scala di DECIMAL (ma non esagerare)

7. Riepilogo

MySQL offre un’ampia varietà di tipi di dati, e il tipo che scegli può influenzare significativamente prestazioni, scalabilità e manutenibilità.
Soprattutto in ambienti come le applicazioni web dove i dati tendono a crescere, le decisioni di progettazione precoce impattano direttamente sulla qualità a lungo termine.

Punti chiave di questo articolo

• I tipi di dati sono fattori critici che influenzano “tipo di valore, intervallo, precisione, archiviazione e prestazioni.”
• I tipi numerici, stringa, data/ora, JSON, ENUM/SET e BLOB hanno ciascuno punti di forza e debolezze.
• Interi, stringhe e tipi data/ora sono i più usati, quindi sceglierli correttamente è importante.
• JSON e ENUM sono comodi, ma un uso improprio può rendere difficile la manutenzione.
• L’uso eccessivo di TEXT e BLOB può degradare le prestazioni.
• Un approccio di progettazione razionale è: “Scopo → Intervallo → Prestazioni → Scalabilità.”

Una checklist di progettazione che puoi usare a partire da oggi

• Lo scopo della colonna è chiaramente definito?
• Hai compreso i valori massimi e minimi possibili?
• C’è evidenza alla base della lunghezza VARCHAR scelta?
• Stai usando DECIMAL per il denaro?
• I timestamp “updated at” sono gestiti con TIMESTAMP e auto‑update dove opportuno?
• Prima di usare ENUM, hai considerato se i valori potrebbero aumentare in futuro?
• Stai evitando progetti in cui la ricerca diventa lenta a causa dell’uso eccessivo di JSON?
• Hai progettato per evitare operazioni pesanti di ALTER TABLE su dataset di grandi dimensioni?

Infine

Non esiste sempre una “risposta corretta” unica per la scelta dei tipi di dato MySQL.
Tuttavia, se scegli con uno scopo preciso e tenendo conto della crescita futura, puoi prevenire problemi importanti e mantenere la tua struttura dati pulita.

In definitiva, la scelta migliore dipende dalla natura del tuo progetto, dal volume dei dati e dai requisiti dell’applicazione. Ma se utilizzi i criteri introdotti in questo articolo come base, dovresti essere in grado di fare scelte migliori sui tipi di dato in qualsiasi situazione.

Successivamente, introdurremo una sezione FAQ che riassume le domande più frequenti nel lavoro reale.
Quando non sei sicuro della selezione del tipo, consultare prima questa FAQ ti aiuterà a decidere più agevolmente.

8. FAQ

Scegliere i tipi di dato MySQL è un ambito in cui le decisioni possono variare notevolmente a seconda dell’esperienza pratica.
Qui raccogliamo le domande comuni dei team di sviluppo e forniamo risposte brevi e chiare.

Q1. Devo usare INT o BIGINT?

R: Usa INT per impostazione predefinita. Usa BIGINT solo se potrebbe superare i 2,1 miliardi in futuro.

INT (4 byte) supporta fino a circa 2,1 miliardi ed è sufficiente per la maggior parte delle applicazioni.
Considera BIGINT per log, servizi ad alto traffico o sistemi che potrebbero generare un numero estremamente elevato di ID.

Q2. Devo usare VARCHAR o TEXT?

R: Usa VARCHAR se hai bisogno di ricerca. Usa TEXT per contenuti lunghi.

• VARCHAR : Indicizzabile e migliore per le ricerche
• TEXT : Ideale per contenuti estesi ma non ottimale per ricerche o JOIN

※ L’uso eccessivo di TEXT può portare a degrado delle prestazioni.

Q3. È accettabile memorizzare denaro come DOUBLE?

R: No. Usa sempre DECIMAL.

DOUBLE e FLOAT possono introdurre errori di arrotondamento, quindi non sono adatti per denaro o valori che richiedono precisione.
Nei sistemi aziendali, DECIMAL(10,2) o DECIMAL(12,2) è uno standard comune.

Q4. Non capisco la differenza tra DATETIME e TIMESTAMP. Come devo scegliere?

R: Usa TIMESTAMP se ti servono auto‑update. Usa DATETIME se devi memorizzare un timestamp preciso senza conversione del fuso orario.

• TIMESTAMP : Auto‑update e conversione del fuso orario
• DATETIME : Non influenzato dai fusi orari; memorizza la data/ora “così com’è”

DATETIME è spesso usato per log e tabelle di cronologia.

Q5. È sicuro usare ENUM?

R: È utile solo quando i valori sono “garantiti immutabili”.

ENUM è leggero e comodo, ma aggiungere o modificare valori richiede ALTER TABLE.
Per campi che potrebbero crescere, è consigliata la gestione master in una tabella separata.

Q6. Posso semplicemente usare JSON per ora?

R: Usa JSON solo per dati che non cerchi. I dati che cerchi dovrebbero essere normalizzati.

JSON è flessibile, ma presenta debolezze di prestazione.

• Debole per le ricerche
• Le strutture di indice diventano più complesse
• Più difficile mantenere la coerenza dei dati

Funziona bene per impostazioni e opzioni—attributi che non vengono usati come condizioni di ricerca.

Q7. Come devo decidere la lunghezza massima per VARCHAR?

R: Stima il massimo basandoti sui dati reali e aggiungi un piccolo margine.

Esempio: Indirizzo email → VARCHAR(100) è sufficiente
Esempio: Nome utente → VARCHAR(50) è spesso adeguato

“255 solo perché” non è consigliato.

Q8. Se scelgo il tipo sbagliato, posso cambiarlo in seguito?

R: Sì, ma può essere molto oneroso su tabelle grandi.

ALTER TABLE spesso comporta scansioni complete e ricostruzioni,
il che può causare downtime o lunghi periodi di lock.

→ Una pianificazione attenta nella fase di progettazione iniziale è la più importante