Vous allez regretter d’utiliser des clés naturelles

• Les clés naturelles sont des clés utilisées dans une base de données pour garantir l’unicité
• Elles reposent sur des données réelles, comme un nom, une ville ou une année
• Par exemple, dans une base de données des 50 meilleurs restaurants du monde, on pourrait utiliser restaurantName, cityName et year comme clé naturelle
• Cependant, une clé naturelle peut ne pas garantir l’unicité. Par exemple, des restaurants portant le même nom peuvent exister dans plusieurs villes

Identité

• Au-delà de l’unicité, une clé naturelle doit aussi garantir l’identité
• Par exemple, le numéro de châssis d’une voiture ou un numéro d’identification personnel (numéro CPR) peuvent être utilisés comme clé naturelle
• Mais une même personne peut avoir plusieurs numéros d’identification. Par exemple, au Danemark, une personne transgenre peut recevoir un nouveau numéro CPR

Erreurs administratives

• Les clés naturelles sont vulnérables aux erreurs administratives
• Des erreurs de saisie, des fautes de frappe utilisateur ou des erreurs de conversion de données peuvent survenir
• Le système doit pouvoir corriger ces erreurs. Il n’est donc pas approprié d’utiliser des clés externes comme clés de base de données

Conclusion

• Utiliser des clés naturelles dans la conception d’une base de données n’est pas une bonne idée
• Des erreurs de données peuvent se produire, et il faut pouvoir les corriger
• Il est donc recommandé d’utiliser systématiquement des clés artificielles dans les tables d’une base de données

L’avis de GN⁺

• Problèmes des clés naturelles : elles peuvent ne pas garantir l’unicité ni l’identité, et sont vulnérables aux erreurs de saisie.
• Avantages des clés artificielles : elles garantissent l’unicité et l’identité, et permettent de corriger plus facilement les erreurs de données.
• Points à considérer avec un ORM : lorsqu’on utilise une bibliothèque ORM, il est plus simple d’employer des clés artificielles. Comme un ORM détermine en partie la structure de la base de données, cette approche est plus efficace.
• Produits aux fonctionnalités similaires : d’autres outils de conception de base de données ou bibliothèques ORM recommandent également l’usage de clés artificielles, comme Hibernate ou Entity Framework.
• Points à considérer lors de l’adoption d’une technologie : lors de la mise en place d’une nouvelle conception de base de données, il est préférable de tenir compte des limites des clés naturelles et d’utiliser des clés artificielles. Celles-ci garantissent l’intégrité des données et facilitent la correction des erreurs.

[GN⁺]

Commentaire Hacker News

• ID uniques, courts et lisibles par des humains : préférence pour des identifiants comme cus_MJA953cFzEuO1z, utilisés par Stripe. Il existe aussi une façon de les générer en JavaScript/TypeScript.
• Numéros d’identification personnelle : comparaison entre le numéro CPR du Danemark et le SSN américain. Le SSN n’est pas unique, peut être modifié et peut être attribué même à des non-citoyens américains. Il est déconseillé de l’utiliser comme clé de base de données.
• Alias et journaux d’audit : lorsqu’on utilise une clé naturelle comme le numéro CPR danois, il faut une table séparée pour enregistrer les changements. Les URL peuvent aussi servir de clés naturelles, mais il faut alors créer une table de redirection en cas de modification.
• Limites des clés naturelles : si un identifiant unique change, il faut suivre toutes les informations associées. Ajouter une clé artificielle augmente encore la quantité d’informations à suivre. La modélisation des données doit refléter le monde réel.
• Clés naturelles et protection de la vie privée : si une clé naturelle contient des informations personnelles, elles peuvent se propager à d’autres tables via les clés étrangères.
• Exemple des gamertags : cas d’usage où le gamertag du PlayStation Network sert de clé naturelle. Si le gamertag ne change pas, il peut être utilisé comme identifiant unique.
• Exemple dans le domaine médical : des problèmes surviennent lorsqu’un agent d’enregistrement saisit un mauvais numéro de santé personnel (PHN). Avec une clé artificielle, une correction reste possible plus tard.
• Absence de contrôle sur les clés naturelles : les noms, adresses, numéros d’enregistrement officiels, etc. ne sont pas sous votre contrôle et ne sont donc pas fiables. Il faut utiliser un système de clés uniques.
• Utilisation de clés artificielles : employer un champ d’ID unique dans chaque table facilite la résolution des problèmes. Comme les données et les relations changent souvent, il est difficile de faire confiance aux clés naturelles.
• Mutabilité et ID uniques : la possibilité de changement implique le besoin d’un identifiant commun à travers le temps. La base de données doit inclure des clés de substitution explicites dans le schéma.

[jsonobject]

Je recommande aussi, pour les clés artificielles, d’utiliser un TSID prêt à fonctionner dans des environnements distribués compatibles avec les régions globales, entre autres. J’utilise des TSID comme PK dans MySQL et DynamoDB.

https://jsonobject.hashnode.dev/using-tsid-as-database-pk