Ni SQL ni le modèle relationnel ne sont perturbés par des clés étrangères qui référencent une clé naturelle. En fait, le référencement de clés naturelles améliore souvent considérablement les performances. Vous seriez surpris de voir combien de fois les informations dont vous avez besoin sont complètement contenues dans une clé naturelle; référencer cette clé échange une jointure pour une table plus large (et réduit par conséquent le nombre de lignes que vous pouvez stocker sur une page).
Par définition, les informations dont vous avez besoin sont toujours entièrement contenues dans la clé naturelle de chaque table de "recherche". (Le terme table de recherche est informel. Dans le modèle relationnel, toutes les tables ne sont que des tables. Une table de codes postaux américains peut avoir des lignes qui ressemblent à ceci: {AK, Alaska}, {AL, Alabama}, {AZ, Arizona} , etc. La plupart des gens appellent cela une table de recherche.)
Sur les grands systèmes, il n'est pas rare de trouver des tables qui ont plus d'une clé candidate. Il n'est pas rare non plus que les tables qui servent à une partie de l'entreprise à référencer une clé candidate et les tables qui servent à une autre partie de l'entreprise à référencer une clé candidate différente. C'est l'un des points forts du modèle relationnel, et il fait partie du modèle relationnel que SQL supporte assez bien.
Vous rencontrerez deux problèmes lorsque vous référencerez des clés naturelles dans des tables qui ont également une clé de substitution.
Tout d'abord, vous surprendrez les gens. Bien que je fasse habituellement du lobbying pour le principe de la moindre surprise je fasse , c'est une situation où je ne me dérange pas de surprendre les gens. Lorsque le problème est que les développeurs sont surpris par l'utilisation logique des clés étrangères, la solution est l'éducation, pas la refonte.
Deuxièmement, les ORM ne sont généralement pas conçus autour du modèle relationnel, et ils incarnent parfois des hypothèses qui ne reflètent pas les meilleures pratiques. (En fait, ils semblent souvent avoir été conçus sans jamais avoir à faire appel à un professionnel de la base de données.) Exiger un numéro d'identification dans chaque table est l'une de ces hypothèses. Un autre suppose que l'application ORM "possède" la base de données. (Il est donc gratuit de créer, supprimer et renommer des tables et des colonnes.)
J'ai travaillé sur un système de base de données qui a servi des données à des centaines de programmes d'application écrits dans au moins deux douzaines de langues sur une période de 30 ans. Cette base de données appartient à l'entreprise et non à un ORM.
Une fourchette qui introduit des changements de rupture devrait être un arrêtoir.
J'ai mesuré les performances avec des clés naturelles et des clés de substitution dans une entreprise où je travaillais. Il y a un point de basculement où les clés de substitution commencent à surpasser les clés naturelles. ( En supposant qu'aucun supplémentaire effort nécessaire pour maintenir les performances des clés naturelles à un niveau élevé, comme le partitionnement, les index partiels, les index basés sur les fonctions, les espaces de table supplémentaires, l'utilisation de disques SSD, etc.) D'après mes estimations pour cette société, ils atteindront ce point de basculement dans vers 2045. En attendant, ils obtiennent de meilleures performances avec des touches naturelles.
Autres réponses pertinentes: Dans le schéma de la base de données Confus