Types de Données pour Passeport et Identifiants en SQL : Erreurs de Stockage

L'article explique pourquoi pour stocker les numéros de passeport et autres identifiants en bases de données SQL, des types de données chaîne doivent être utilisés, et non numériques. Sémantique des données, problème des zéros initiaux et exemples d'erreurs pratiques sont examinés. Un tableau des types corrects pour les identifiants russes est fourni.

By Sudonull Editorial Team • Published 2026-04-08 • Updated 2026-04-08

Passeport en Base de Données : Pourquoi VARCHAR, Pas INTEGER

Types de données pour les identifiants : pourquoi les numéros de passeport ne sont pas des entiers

Une simple question sur le choix du bon type de données pour stocker les numéros de passeport en base SQL divise les développeurs en deux camps : ceux qui réfléchissent à la sémantique des données et ceux qui suivent bêtement la routine. Choisir INTEGER au lieu de VARCHAR supprime les zéros initiaux et casse l'identification, ce qui est critique dans les systèmes gérant des millions d'utilisateurs. Cet article décortique un principe fondamental de conception de schémas de base de données basé sur la nature des données, pas sur leur apparence.

Sémantique des données vs apparence

La plupart des développeurs, voyant des chiffres dans un numéro de passeport lors d'un entretien, choisissent instinctivement des types numériques comme INTEGER ou BIGINT. C'est une erreur classique due à une analyse superficielle. La question clé n'est pas de quoi est faite la donnée, mais comment elle est utilisée. On ne fait jamais d'opérations arithmétiques sur les séries ou numéros de passeport — on les compare pour l'égalité, on les recherche et on les transmet. Ce sont des identifiants, pas des quantités. Le bon choix est donc un type chaîne : CHAR(4) pour la série et CHAR(6) pour le numéro, ou CHAR(10) pour la valeur combinée. Stocker en INTEGER supprime irrémédiablement les zéros initiaux : 0306 devient 306, invalidant le document sans erreur enregistrée.

Conséquences réelles de l'erreur en production

Choisir le mauvais type de données n'est pas théorique — ça frappe la production régulièrement. Prenons un service de permis de stationnement où le champ passeport en NUMBER a silencieusement supprimé un zéro initial, désynchronisant les enregistrements de base avec les documents papier. Ça a passé les revues de code et les tests jusqu'à toucher les utilisateurs avec des séries commençant par zéro. En Russie, des millions de tels passeports existent, amplifiant massivement le problème. Les arguments d'optimisation comme l'économie d'espace ou la vitesse d'index ne tiennent pas :

CHAR(4) prend les mêmes 4 octets que INTEGER pour des chiffres mono-octet.
Les index VARCHAR performent en O(log n), comme les numériques, avec des différences négligeables pour les chaînes fixes.

L'économie d'octets ne justifie pas les risques de perte de données.

Appliquer la règle à d'autres identifiants

La règle « si vous ne faites pas de maths dessus, ce n'est pas un nombre » s'applique à de nombreux identifiants dans les systèmes russes et mondiaux. Exemples clés :

SNILS (11 chiffres, format XXX-XXX-XXX XX) : Stocker en VARCHAR(14) ou CHAR(11) après suppression des tirets, pas BIGINT.
NIF personnel (12 chiffres) : Peut commencer par zéro pour les régions 01–09, donc VARCHAR(12) obligatoire.
Numéro de téléphone : VARCHAR(20) uniquement, pour garder le '+' des formats internationaux.
Code postal : CHAR(6), car les internationaux peuvent être alphanumériques.
Compte bancaire (20 chiffres) : CHAR(20), car les types numériques ne gèrent pas cette longueur sans débordement.

Les types chaînes assurent la flexibilité et préviennent les pertes dues aux changements de format.

Points clés à retenir

Sémantique d'abord : Choisir le type de données selon les opérations, pas l'apparence.
Zéros initiaux critiques : Les numériques les suppriment, cassant les identifiants pour des millions d'enregistrements.
Optimisation ensuite : Ne pas échanger des économies d'octets ou microsecondes contre de mauvaises données.
Principe universel : Couvre SNILS, NIF, téléphones et plus.
Auditez vos schémas : Vérifiez les bases existantes pour les risques cachés.

Comment choisir le bon type de données

Un bon ingénieur se pose trois questions en concevant un champ de base de données :

Quelle est la sémantique ? (Identifiant, quantité, texte ?)
Quelles opérations ? (Comparer, chercher, calculer ?)
Quelles règles métier ? (Format, longueur, caractères ?)

Les réponses dictent le choix : chaînes pour les identifiants, numériques pour les quantités. Cela distingue la résolution de problèmes du copié-collé et évite les bugs coûteux en amont.

Types de données pour les identifiants russes

|--------|--------|----------|-----------------|---------------------|

Ce tableau est votre fiche de référence pour la conception de schémas et les audits.

— Editorial Team

Communauté

Aucun commentaire pour le moment.

Lire ensuite

Sujets

Bases de Données Développement Backend

FAQ

Pourquoi ne Peut-on Pas Stocker le Passeport comme INTEGER en SQL ?

Parce qu'INTEGER supprime les zéros initiaux, par exemple la série 0306 devient 306, ce qui rend le document invalide. Le passeport est un identifiant sur lequel aucune opération arithmétique n'est effectuée.

Quel Type de Données Utiliser pour SNILS et INN ?

Pour SNILS utilisez CHAR(11) ou VARCHAR(14), pour INN individuel — CHAR(12). Ce sont des types chaîne qui préservent les zéros initiaux et le format.

Le Choix de VARCHAR Affecte-t-il les Performances des Index ?