Conception base de données : pourquoi les numéros de téléphone doivent être stockés en chaînes

Dans pratiquement tous les systèmes de base de données, un champ numéro de téléphone doit utiliser un type de données chaîne (VARCHAR/TEXT) — jamais numérique (INT, BIGINT, DECIMAL).

Raisons

1. Caractères de formatage : Parenthèses, tirets, espaces, points, signes plus — ex. +1 (555) 123-4567, 011-44-20-7123-4567.
2. Zéros initiaux significatifs : De nombreux pays ont des zéros initiaux significatifs (ex. UK 020, Italie 06). Les types numériques les suppriment.
3. Indicatifs pays et extensions : +44 20 7123 4567 poste 123 — « poste » ou « x » alphanumérique.
4. Variabilité longueur : 4–15+ chiffres selon ITU-T E.164 ; limites numériques (BIGINT max 19 chiffres) risquent débordement avec formatage.
5. Codes numérotation non-chiffres : * , # , pauses (,), attentes (;) dans chaînes de numérotation.
6. Recherche/Indexation : Motifs LIKE, correspondances partielles, normalisation E.164 — toutes opérations sur chaînes.

Schéma meilleure pratique

CREATE TABLE contacts ( id BIGSERIAL PRIMARY KEY, phone_e164 VARCHAR(20) NOT NULL, -- normalisé : +15551234567 phone_display VARCHAR(30), -- formaté pour UI : (555) 123-4567 phone_type VARCHAR(10), -- mobile, fixe, voip, fax extension VARCHAR(10), -- optionnel UNIQUE (phone_e164) );

Astuce normalisation

Stockez deux colonnes : un phone_e164 canonique (chiffres seulement, + initial) pour indexation/recherches, et un phone_display pour formatage utilisateur. Supprimez tous non-chiffres à l'entrée ; appliquez libphonenumber (bibliothèque Google) pour validation/formatage.