Envoyé par
Aquellito
Autant utiliser le login en clé primaire, ça évite les doublons et ça évite d'indexer les logins dans ta base.
D’accord pour les doublons, mais pour le reste...
D’une manière générale, un identifiant (par voie de conséquence une clé primaire en SQL) doit être non significatif et invariant. Or un login peut être modifié (ça arrive chez Developpez.com...) et alors attention si des clés étrangères y font référence.
Comme dit Yves Tabourier dans son remarquable ouvrage De l’autre côté de MERISE (Les Éditions d’organisation, 1986) :
« ... la fonction d’une propriété est de décrire les objets (et les rencontres), alors que l’identifiant ne décrit rien. Son rôle fondamental est d’être sûr de distinguer deux jumeaux parfaits, malgré des descriptions identiques.
L’expérience montre d’ailleurs que l’usage des “identifiants significatifs” (ou “codes significatifs”) a pu provoquer des dégâts tellement coûteux que la sagesse est d’éviter avec le plus grand soin de construire des identifiants décrivant les objets ou, pis encore, leurs liens avec d’autres objets... »
Remontons le passé et situons-nous par exemple en 2005. Imaginez une application dans laquelle la clé primaire de la table VEHICULE est {NoImmat} où NoImmat représente le numéro d’immatriculation des véhicules en France : chaque véhicule est identifié par son immatriculation. Comme par hasard, un développeur livre des programmes dans lesquels il se sert des deux chiffres de droite pour tirer des conclusions sur la localisation du véhicule dans quelque département. En 2009, un nouveau système d’immatriculation est mis en place, celui qu’on utilise actuellement en France. Quelles conséquences sur les programmes existants ? Sur la base de données ? (En effet, il se peut que plusieurs tables référencent la table VEHICULE par le mécanisme des clés étrangères...)
Un exemple dont je me sers de temps en temps : il s’agit du système préconisé par les concepteurs dans une très grande banque, consistant à identifier les entreprises par leur numéro Siren, fourni par un organisme extérieur, à savoir l’INSEE. Par voie de conséquence, au niveau du MLD (Modèle Logique de Données selon Merise), puis SQL, ce Siren devait être propagé dans toute la base de données par le jeu des liens clé primaire - clé étrangère. Les concepteurs avaient entrepris le montage d’une véritable usine à gaz pour maintenir la cohérence entre les tables, parce que l’INSEE envoyait tous les mois les nombreux correctifs modifiant les numéros de Siren erronés. En pensant à ce qu’avait écrit Y. Tabourier, je leur suggérai que l’identifiant de l’entreprise fît l’objet d’une propriété nouvelle et artificielle, invariante et sans signification, EntrepriseId, le numéro Siren devenant pour sa part identifiant alternatif, c'est-à-dire conservant sa spécificité : être unique et pouvant subir toutes les modifications de la part de l’utilisateur. Au niveau MLD et SQL, l’ex clé primaire, le numéro Siren devint donc clé alternative, point d'entrée dans la table, permettant à l'utilisateur d’accéder aux données de chaque entreprise, la suite des opérations se passant de façon transparente, encapsulée pour utiliser un jargon à la mode, grâce à la nouvelle clé primaire EntrepriseId : du point de vue de l’utilisateur et des règles fonctionnelles, rien de changé, mais l’usine à gaz disparut en fumée, des économies furent réalisées, et tout le monde fut content.
Conseil de modélisation
Répondre avec citation
Partager