IA et bases de données MySQL

Une erreur notable est que de nombreux schémas de base de données générés par IA favorisent actuellement l'utilisation de VARCHAR(36) pour la colonne id.

Ceci est généralement motivé par un désir de prévenir l'accès non autorisé par des acteurs malveillants. Pour y parvenir, les UUID (Identifiants Universellement Uniques) sont souvent employés comme mesure de sécurité.

Prenons WordPress comme exemple — il expose généralement les ID de posts dans l'URL comme ?p=45. Comparé à un format SEO-friendly tel que /2025/05/sample-post, cet ID numérique permet aux utilisateurs de potentiellement deviner et accéder au contenu adjacent en modifiant le nombre (par exemple, ?p=44). Les UUID, d'autre part, ne sont pas séquentiels et sont beaucoup plus difficiles à deviner.

Les UUID sont des chaînes de 36 caractères qui suivent un format standard avec cinq sections séparées par des tirets: 8-4-4-4-12. Chaque section est composée de valeurs hexadécimales:

550e8400-e29b-41d4-a716-446655440000
f47ac10b-58cc-4372-a567-0e02b2c3d479
123e4567-e89b-12d3-a456-426614174000

Une expression régulière simple pour valider les UUID ressemble à ceci:

^[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}$

Bien que les UUID offrent sécurité et portabilité, ils viennent avec des compromis. Ils sont significativement plus grands que les entiers, ce qui peut ralentir les performances de la base de données — surtout quand utilisés comme clés primaires dans les bases de données relationnelles. L'indexation, l'utilisation de la mémoire et la vitesse des requêtes souffrent toutes à cause de la taille et de la nature non-séquentielle des UUID.

Une conversation IA sur la stratégie d'ID

Curieux de ce choix de conception, j'ai posé la question suivante à GitHub Copilot:

Moi:
Pourquoi avez-vous choisi de définir la colonne id comme VARCHAR(36) PRIMARY KEY dans la structure de base de données?

GitHub Copilot:

J'ai choisi VARCHAR(36) pour les colonnes ID pour quelques raisons spécifiques:

1. Stockage UUID: La longueur de 36 caractères correspond aux valeurs UUID, qui suivent un format standardisé.
2. Systèmes multi-locataires: Les UUID aident à isoler les locataires en éliminant les fuites d'ID séquentiels, simplifiant les migrations et améliorant la sécurité.
3. Portabilité des données: Les UUID garantissent que les données exportées ne souffrent pas de collisions d'ID lors de l'importation dans un autre système.

Compromis:

• Taille de stockage plus grande (36 octets vs 4 octets pour INT)
• Performance d'indexation et de requête plus lente
• Utilisation mémoire accrue

Alternatives à considérer:

1. AUTO_INCREMENT INT/BIGINT
2. BINARY(16) pour stocker les octets UUID bruts plus efficacement
3. Une stratégie de génération d'ID personnalisée

Faites-moi savoir si vous préférez une approche différente.

Moi:
Utilisez BIGINT UNSIGNED pour les performances, mais gardez un champ guid dans chaque enregistrement pour les références externes.

GitHub Copilot:

Je vais mettre à jour le schéma pour utiliser BIGINT UNSIGNED comme clé primaire tout en ajoutant une colonne guid pour les références externes. Cette approche hybride combine le meilleur des deux stratégies:

• Performance: Indexation et jointures efficaces via des clés primaires numériques
• Sécurité et Portabilité: GUID exposés dans les API, rendant les ID internes sûrs contre l'énumération

Résumé:

• BIGINT UNSIGNED: Rapide, compact, séquentiel
• GUID (VARCHAR): Unique, portable, externellement sûr

Bases de données NoSQL et ObjectIds MongoDB

Tandis que les bases de données relationnelles offrent la flexibilité de choisir entre UUID, entiers ou hybrides, les systèmes NoSQL comme MongoDB prennent un chemin différent.

MongoDB utilise un type intégré appelé ObjectId pour son champ _id. C'est une valeur binaire de 12 octets qui encode:

• 4 octets – Horodatage (secondes depuis l'époque)
• 5 octets – Valeur aléatoire (souvent basée sur machine + ID de processus)
• 3 octets – Compteur incrémental

Exemple:

507f1f77bcf86cd799439011

Pourquoi MongoDB choisit ObjectId

1. Globalement unique sans coordination
   Similaire aux UUID, les ObjectId ne nécessitent pas d'autorité centrale pour assurer l'unicité, les rendant idéaux pour les environnements distribués.
2. Ordonné dans le temps
   L'horodatage intégré signifie que les documents sont grossièrement triés chronologiquement par défaut, ce qui peut aider les performances dans les applications de séries temporelles.
3. Compact et efficace
   Stockés en binaire, les ObjectId ne prennent que 12 octets — beaucoup plus petit qu'un UUID VARCHAR(36). Ils sont aussi plus favorables à l'indexation.

Comparaison des stratégies d'ID

Préférences IA dans les contextes NoSQL

Beaucoup de systèmes générés par IA utilisent par défaut des configurations NoSQL similaires à MongoDB quand:

• Un débit d'écriture élevé ou le sharding est attendu
• Les schémas doivent être flexibles ou semi-structurés
• La portabilité des données et la mise à l'échelle distribuée sont des priorités

Dans ces cas, utiliser des ObjectId ou des identifiants uniques similaires, triables dans le temps, est souvent un défaut sensé.

PrimeCRM