Progettazione database: perché i numeri di telefono vanno memorizzati come stringhe

In praticamente ogni sistema di database, un campo numero di telefono dovrebbe usare un tipo di dati stringa (VARCHAR/TEXT) — mai numerico (INT, BIGINT, DECIMAL).

Motivi

1. Caratteri di formattazione: Parentesi, trattini, spazi, punti, segni più — ad esempio, +1 (555) 123-4567, 011-44-20-7123-4567.
2. Zeri iniziali importanti: Molti paesi hanno zeri iniziali significativi (es. UK 020, Italia 06). I tipi numerici li eliminano.
3. Prefissi internazionali ed estensioni: +44 20 7123 4567 ext. 123 — alfanumerico "ext." o "x".
4. Variabilità di lunghezza: 4–15+ cifre per ITU-T E.164; limiti numerici (BIGINT max 19 cifre) rischiano overflow con formattazione.
5. Codici di selezione non numerici: *, # , pause (,), attese (;) nelle stringhe di selezione.
6. Ricerca/Indicizzazione: Pattern LIKE, corrispondenze parziali, normalizzazione E.164 — tutte operazioni su stringhe.

Schema di best practice

CREATE TABLE contacts (
 id BIGSERIAL PRIMARY KEY,
 phone_e164 VARCHAR(20) NOT NULL, -- normalizzato: +15551234567
 phone_display VARCHAR(30), -- formattato per UI: (555) 123-4567
 phone_type VARCHAR(10), -- mobile, landline, voip, fax
 extension VARCHAR(10), -- opzionale
 UNIQUE (phone_e164)
);

Consiglio per la normalizzazione

Memorizza due colonne: un phone_e164 canonico (solo cifre, iniziale +) per indicizzazione/ricerche, e un phone_display per la formattazione visibile all'utente. Rimuovi tutti i non-cifre in input; applica libphonenumber (libreria di Google) per validazione/formattazione.