Une clé de substitution doit-elle jamais être exposée à un utilisateur?

14

Souvent dans une table qui n'a pas de clé naturelle, il est toujours utile pour les utilisateurs d'avoir un identifiant généré de manière unique. Si la table a une clé primaire de substitution (et dans ce cas, vous vous en doutez certainement), cette clé devrait-elle être exposée à l'utilisateur ou un autre champ devrait-il être utilisé à cette fin?

Une raison de ne pas exposer la clé de substitution est que vous ne pouvez plus effectuer d'opérations qui préservent la relation entre les enregistrements, mais modifier les valeurs de clé, telles que certains types de suppression / réinsertion, de nombreuses méthodes de copie de données d'une base de données vers un autre, etc.

Le principal avantage d'exposer la clé de substitution est la simplicité d'utilisation d'un champ que vous avez de toute façon.

Dans quelles circonstances est-il préférable d'exposer directement la clé de substitution aux utilisateurs?

design database-design relational-database rdbms surrogate-keys psr
la source
Une partie de cette question est que vous devez définir les «utilisateurs». Les utilisateurs peuvent être des consommateurs d'une API que vous exposez ou des êtres humains charnus. La réponse ne sera pas la même pour les deux.
James Snell
1
Des êtres humains charnus.
psr
Chaque situation où les données pourraient être identifiées différemment devrait avoir un identifiant différent. Donc, si un nouveau système se connecte à vos données, attendez-vous à ce qu'il ait son propre PK et ajoutez-le à vos données. La visibilité des «sacs moches de la plupart du temps de l'eau» compte comme un «système» pour ce scénario. Ma solution préférée est de stocker les clés et les horodatages (ajouter et modifier et supprimer) pour les entités dans une table spéciale. De cette façon, les données peuvent être facilement distribuées.

Réponses:

10

Vous devez être prêt pour tout identificateur exposé aux utilisateurs / clients devant être modifiés, et changer l'identité d'une ligne dans une base de données et propager ce changement à toutes les clés étrangères demande simplement de casser les données.

Si les données n'ont pas de clé d'entreprise naturelle, vous pouvez ajouter un champ supplémentaire pour un "identifiant d'entreprise". Cela devrait être optimisé pour les processus pour lesquels il est utilisé. La saisie au clavier du téléphone signifie uniquement numérique. Au téléphone / verbal, évitez les symboles similaires (B / D, M / N, etc.). Vous pouvez même générer automatiquement une phrase facilement mémorisable ("gelée verte").

Cela a pour effet que l'entreprise peut modifier ultérieurement la manière dont elle souhaite faire référence aux enregistrements, et la seule modification du schéma de données consiste à ajouter une nouvelle colonne pour ce style d'ID ou à transformer les ID déjà présents. Le changement ne se propage pas à travers la base de données entière et vous avez toujours un identifiant (le substitut) qui est valide dans le temps.

En bref, j'éviterais d'exposer des clés de substitution aux utilisateurs. Comme le soulignent les commentaires, les clés de substitution ne devraient presque jamais changer. À l'inverse, les entreprises veulent tout changer. Si la clé de substitution est exposée, ce n'est qu'une question de temps avant que l'entreprise veuille la changer.

En guise de remarque, lorsque je dis «exposer» ici, je veux donner la clé à l'utilisateur dans l'attente qu'il l' utilise directement (comme appeler pour prendre en charge avec son numéro de commande).

Chris Pitman
la source
5
Cette réponse n'a aucun sens. Les clés de substitution ne changent jamais, et vous n'avez pas plaidé pour ne pas les exposer aux utilisateurs.
Robert Harvey
1
ne jamais dire jamais. que se passe-t-il si cette dernière conception entraîne une consolidation des enregistrements? que se passe-t-il si vous avez besoin de migrer et de vous éloigner des identités?
DougM
3
@DougM: Ensuite, écrivez les enregistrements dans une nouvelle table consolidée avec sa propre clé de substitution et conservez les clés d'origine dans des champs séparés de la nouvelle table (et un champ qui identifie la table source d'origine) comme références, si nécessaire. Ce type de consolidation devrait être extraordinairement rare, et uniquement en raison d'une conception bâclée. Répétez après moi: Surrogate. Clés. Jamais. Changement. Voilà pourquoi ce sont des substituts.
Robert Harvey
2
@RobertHarvey Je suis d'accord que les clés de substitution ne devraient jamais changer, c'est pourquoi je pense qu'elles font de mauvais identifiants externes. Finalement, un client voudra changer la façon dont il se réfère à un enregistrement. À ce stade, vous avez soit construit l'ensemble de votre système autour de clés de substitution immuables, soit vous avez anticipé et mis un niveau d'indirection entre les identifiants d'entreprise et les clés de substitution.
Chris Pitman
2
@sqlvogel: Serait-il plus clair si j'utilisais le terme "clé primaire générée par le système" au lieu de "substitut?" Je suis d'accord que vous voudrez peut-être changer l'algorithme qui génère les clés de substitution, mais cela ne change pas leur qualité fondamentalement immuable.
Robert Harvey
4

Dans certains cas, des clés de substitution sont attendues et ont un sens pour les utilisateurs. Mon exemple préféré est "numéro de commande". Le numéro de commande n'est pas vraiment une clé naturelle: une clé naturelle peut être l'horodatage plus l'utilisateur, ou peut-être plus que cela si vous vous attendez à ce que les utilisateurs génèrent plus d'une commande dans la granularité de votre horodatage.

Néanmoins, les utilisateurs comprennent et attendent la commodité d'un numéro de commande. Il n'y a aucun mal et beaucoup de valeur si vous en informez les utilisateurs.

D'un autre côté, certaines clés de substitution n'ont aucun sens pour un utilisateur. Bien sûr, ma compagnie d'assurance maladie a une clé de substitution qui m'identifie en fonction de mon identifiant de membre, de ma date de naissance, de mon porteur, etc., mais je m'en fiche, je me soucie des informations sur ma carte (qui comprend souvent sur mon employeur et ne sont pas uniques à travers l'univers ... D'où la clé de substitution à la compagnie d'assurance).

Alan Shutko
la source
Si un utilisateur le comprend et s'attend à interagir avec lui, ce n'est plus une clé de substitution. Les clés de substitution sont définies comme n'ayant aucune signification commerciale. Ce n'est pas parce qu'il s'agit d'un numéro d'identification que c'est nécessairement un substitut. De plus, "une clé de substitution qui m'identifie en fonction de mon identifiant de membre, de la date de naissance [...]" n'a pas de sens. Vous dites que leur clé de substitution (qui n'a aucune signification commerciale) vous identifie en fonction de choses qui pourraient composer une clé naturelle?
Kyle McVay
Souvent, ce qui se passe, c'est qu'on vous attribue un numéro d'identification d'employé de sorte que dans le système des employés, vous vous différenciez des autres personnes du même nom. Sur votre carte d'assurance, il peut indiquer votre identifiant d'entreprise et d'employé. Mais la compagnie d'assurance maladie génère souvent son propre identifiant interne qu'elle peut utiliser dans tous ses systèmes au lieu d'utiliser le nom, la date de naissance et les identifiants des employés qu'elle reçoit de votre employeur. S'agit-il de clés de substitution ou de clés naturelles? Dépend de qui vous demandez (vérifiez 2 définitions alternatives sur en.wikipedia.org/wiki/Surrogate_key )
Alan Shutko
1

Vous ne devez exposer une clé de substitution que s'il s'agit d'un GUID / UUID * correctement généré. L'exposition des clés de substitution séquentielles est le numéro 4 des 10 principaux problèmes de sécurité OWASP.

* En pratique, il est préférable de supposer qu'il n'a pas été correctement généré à ces fins, sauf si vous savez qu'il a été créé par un générateur de nombres aléatoires ou pseudo-aléatoires cryptographiquement sécurisé.

Peter Taylor
la source
2
Il n'est pas clair dans votre réponse comment un GUID améliore la sécurité.
Robert Harvey
1
@RobertHarvey - Je suppose que parce qu'ils ne sont pas séquentiels et ne peuvent donc pas être devinés.
Bobson
1
security.stackexchange.com/q/38777
Robert Harvey
@RobertHarvey, clarifié.
Peter Taylor
1

Si une table n'a pas de clé naturelle, les clés de substitution autorisent des lignes comme celle-ci.

surrogate_key  some_name
--
1              Wibble
2              Wibble
...
17             Wibble
...
235            Wibble

J'appellerais ces clés artificielles au lieu de clés de substitution, mais cette distinction n'est pas importante pour cette question.

Maintenant, en supposant qu'il existe des données importantes référençant ces clés de substitution via des clés étrangères, comment les utilisateurs finaux sauraient- ils quelle ligne mettre à jour s'ils ne connaissent pas les valeurs de clé de substitution?

Mike Sherrill 'Cat Recall'
la source
Il est un peu contradictoire d'étiqueter la colonne "surrogate_key" mais de dire ensuite qu'il s'agit de "clés artificielles au lieu de clés de substitution". Si vous appelez ces clés artificielles parce qu'elles n'ont aucune signification commerciale et ne servent que d'identificateurs uniques, cette clé doit être naturalisée (exposée) et une nouvelle clé de substitution doit être créée. c'est-à-dire, renommer la clé de substitution naturalisée en quelque chose ayant une signification commerciale, l'exposer aux clients et créer une nouvelle colonne similaire pour être la véritable substitution pour les opérations internes. Moins qu'idéal, mais toujours mieux que d'exposer un véritable substitut.
Kyle McVay du
@KyleMcVay: Ce n'est pas contradictoire. Il honore le sens de la substitution , dont l'idée essentielle est de «remplacer». Une clé de substitution remplace une clé naturelle. (Codd et la théorie relationnelle en général utilisent la clé de substitution dans ce sens.) Une table qui n'a pas de clé naturelle ne peut pas avoir de clé de substitution dans ce sens. Mais il peut avoir une valeur arbitraire qui est utilisée à la place de toute autre chose. C'est ce que j'appellerais une clé artificielle.
Mike Sherrill 'Cat Recall'
Vos définitions ne sont pas inexactes, mais je pense que la clé de substitution a pris une signification supplémentaire spécifique à l'industrie au-delà du mot substitution . Si vous allez exposer une clé à un client, je dirais que cette clé a maintenant une signification commerciale; il a été naturalisé et doit désormais être considéré comme faisant logiquement partie de l'entité qu'il représente. Selon cette logique, il n'existe pas de clé de substitution exposée. Si vous allez exposer une clé artificielle, ce n'est plus une clé de substitution et vous en avez besoin d'une nouvelle.
Kyle McVay
0

Dans les mots du profane:

  • Les substituts doivent être cachés à l'utilisateur.
  • Vous devez exposer une autre clé de candidat commercial à l'utilisateur.
  • Si aucune autre clé candidate n'existe, vous devez montrer le PK. Mais dans ce cas, le PK n'est pas considéré comme un substitut car il ne remplace pas une autre colonne.
Tulains Córdova
la source
Pourquoi le PK doit-il être affiché? Je pense que c'est ma question - si un PK généré automatiquement est correctement appelé une clé de substitution est tangentiel.
psr
1
@psr Le titre de votre question indique " les clés de substitution doivent être exposées". J'ai dit non. Mais vous devez montrer une autre clé. Si aucune autre clé n'existe, vous devez montrer la seule clé que vous avez. Tangentiellement, je précise que dans ces cas, la clé n'est pas vraiment un substitut car elle ne se substitue à aucune autre colonne.
Tulains Córdova
La question est de savoir si vous devez ajouter une colonne ou afficher la clé que vous avez.
psr
@psr J'ai reformulé ma réponse pour la rendre plus claire.
Tulains Córdova
1
Je trouve que c'est une distinction matériellement insignifiante. Si votre règle est que chaque table a une clé artificielle (qui est la mienne) et que seules les clés artificielles participent aux jointures (ce qui est aussi mon principe), alors l'idée qu'une clé est un substitut car d'autres clés peuvent éventuellement être disponible est sans conséquence.
Robert Harvey
0

vous devez UNIQUEMENT exposer un champ à un utilisateur qui fournit des informations utiles à l'utilisateur, soit directement, soit pour vous signaler des défauts.

à l'inverse, vous devez TOUJOURS exposer les «clés primaires de substitution» lorsqu'elles sont le principal moyen d'identifier un enregistrement (simple ou complexe) pour une interaction que l'utilisateur effectue.

DougM
la source
0

Peu importe que vous exposiez les clés ou non à l'utilisateur final. Votre application doit effectuer l'autorisation nécessaire de telle sorte que le simple fait de connaître un identifiant de commande, par exemple, ne puisse pas lui permettre d'accéder à quelque chose auquel il n'aurait normalement pas accès.

mise en garde: cela suppose une application Web ou à plusieurs niveaux où l'autorisation côté serveur est possible / faisable. Si vous avez une application VB qui exécute directement SQL, c'est un tout autre problème.

GrandmasterB
la source
Qu'en est-il de ne pas pouvoir insérer puis supprimer des enregistrements, tout en préservant les relations de clé étrangère, comme mentionné dans la question?
psr
Qu'est-ce que cela a à voir avec l'exposition de la clé à l'utilisateur? Peut-être que je ne comprends pas votre utilisation du terme «exposer». Je travaille à partir de l'hypothèse que vous voulez dire «capable d'être vu par l'utilisateur».
GrandmasterB