Parent : [[INDEX-CYBERSECU]]

Anti-Pattern : Schéma tracker avec text NOT NULL, pas de FK, charset latin1

Description

Utiliser text NOT NULL pour des champs optionnels (profile_desc, ban_reason), varchar(255) pour un pays, varchar(11) pour un âge, int(11) comme PK avec 13.7M+ utilisateurs (risque d'overflow), latin1 comme charset (pas UTF-8), et aucune foreign key. Cela crée des données incohérentes, des limitations de croissance, et des problèmes d'internationalisation.

Exemple réel - Archive Ygg

CREATE TABLE `users` (
  `id` int(11) NOT NULL AUTO_INCREMENT,  -- ❌ 13.7M users, overflow imminent
  `age` varchar(11) NOT NULL,             -- ❌ varchar(11) pour un âge
  `country` varchar(255) NOT NULL,        -- ❌ trop large
  `profile_desc` text NOT NULL,           -- ❌ devrait être NULL
  `ban_reason` text NOT NULL,             -- ❌ devrait être NULL
  `settings` text DEFAULT NULL,           -- ✅ correct mais pas JSON type
  PRIMARY KEY (`id`),
  -- ❌ Aucune FOREIGN KEY
) ENGINE=InnoDB AUTO_INCREMENT=13720815 
  DEFAULT CHARSET=latin1 COLLATE=latin1_swedish_ci;  -- ❌ latin1

Conséquences

• Overflow d'ID : int(11) max = 2.1M, déjà à 13.7M (comment?? - probablement unsigned int mais toujours limité)
• Données incohérentes : Pas de FK = orphans, références cassées
• Problèmes d'encodage : latin1 = pas de support international
• Espace gaspillé : text NOT NULL = stockage obligatoire
• Mauvaise validation : pas de type DATE pour birth_date

Quand c'est acceptable

JAMAIS pour un nouveau projet. Legacy code uniquement avec migration planifiée.

Solution

Utiliser KNOW-PAT-064 — Schéma de base de données tracker hardening :

• bigint UNSIGNED pour l'ID
• utf8mb4 pour le charset
• JSON natif pour les structures
• Foreign keys
• Types appropriés (DATE, char(2), etc.)

Références

• Archive Ygg : 03_DATABASES/ygg_tracker_redacted/users_schema.sql
• OWASP : Database Security