Je me demandais quelles étaient les meilleures pratiques pour la construction et le stockage des ID. Il y a quelques années, un professeur m'a parlé des dangers d'un système d'identification mal construit en utilisant le numéro de sécurité sociale à titre d'exemple. En particulier, car les SSN n'ont pas de détection d'erreur ... il est impossible de dire la différence entre une chaîne à 9 chiffres et une SSN valide. Et maintenant les agences gouvernementales ont besoin de choses comme le nom de famille + SSN ou anniversaire + SSN pour suivre vos données et assurer sa vérification. De plus, votre numéro de sécurité sociale est quelque peu prévisible sur la base de votre naissance.
Maintenant, je construis une base de données d'utilisateurs ... et basé sur ces conseils "Userid IndiomInt Auto_Increment" serait inacceptable. Surtout si je prévois d'utiliser cet identifiant comme identification principale pour l'utilisateur. (Par exemple, si je permet aux utilisateurs de changer de nom d'utilisateur, le nom d'utilisateur serait plus difficile à garder une piste que l'ID utilisateur numérique ... nécessitant des clés étrangères en cascade et ce qu'on puisse changer.) Changement de courriels, les noms d'utilisateur peuvent changer, change de mots de passe. . Mais un ID utilisateur devrait rester constant pour toujours.
Clairement, auto_incrènement est uniquement conçu pour les keys de substitution. C'est-à-dire que c'est un raccourci utile uniquement lorsque vous avez déjà un mécanisme d'identification primaire, mais il ne devrait pas être utilisé comme "identifiant inné" pour les données. Créer un uuid aléatoire semble intéressant, mais le hasard me désactive.
Et donc je demande: Quelles sont les meilleures pratiques pour créer une "clé primaire" numéro d'identification?
7 Réponses :
La meilleure pratique consiste à utiliser un entier d'incrémentation automatique. Il n'y a pas de vraie raison pour laquelle il ne devrait pas être utilisé comme un "identifiant inné". Il fournira l'utilisation la plus compacte dans les clés étrangères et les recherches les plus rapides. Presque toute autre valeur peut changer et est inappropriée pour une utilisation en tant que clé.
Cette valeur serait-elle éventuellement grande à stocker avec de nombreux utilisateurs?
@Mike, utilisez un document 64 bits dans le code et vous ne manquerez jamais de valeurs lors du suivi des utilisateurs. 9,223 372 036 854 775 807 valeurs possibles ou double que si vous utilisez un Int Int 64 non signé.
Vous avez partiellement raison. Mais nous devons garder à l'esprit que si nous n'exposons pas l'identifiant à l'utilisateur, c'est-à-dire pour la recherche, nous ne tireras pas parti des indices en clusters que ce soit.
@kerzek, pouvez-vous expliquer cette déclaration à propos de ne pas tirer parti des indices en cluster? Le plus souvent des identifiants sont utilisés dans des jointures afin que l'indice clustered réduira une étape supplémentaire dans la collecte de données résultant d'une jointure. En outre, vous supposez également une implémentation spécifique avec des index en cluster. Tous les moteurs de stockage MySQL ne prennent pas en charge les index en cluster.
N'est-ce pas un problème lorsque vous l'utilisez à l'extérieur que les gens peuvent facilement obtenir des informations qu'elles ne sont pas censées obtenir (par exemple, quelle vitesse votre base d'utilisateur augmente)?
Et que pensez-vous de Meilleures pratiques de l'utilisateur ID Formation de Witty & Alan ?
@Martinthoma, je pense que cela a une pertinence nulle pour cette question. Witty & Alan parle d'un ID utilisateur dans un scénario où l'ID est utilisé pour identifier les utilisateurs à l'extérieur. Lorsque nous parlons d'un identifiant utilisateur dans une base de données, nous parlons d'un identifiant interne.
@Samuelneff OK. Donc, lire cet article, je peux comprendre pourquoi on voudrait avoir un identifiant externe qui a quelques propriétés différentes. Et pourquoi un identificateur interne est-il différent de celui externe? Je ne pense pas que la différence de taille importera.
@Martinthoma Je ne suis pas intéressé à discuter. Si vous ne voyez pas les avantages, cela va bien, vous pouvez utiliser ce que vous préférez. Gardez également à l'esprit que l'article a 15 ans et cette réponse a 8 ans. Les meilleures pratiques et les directives changent.
comparer les SSN aux entiers incrémentés automatiquement est des pommes et des oranges. Personnellement, j'évite les GUID / UUIDS / UIDS Sauf si de nombreux enregistrements dans le tableau deviennent inefficaces ou déraisonnables d'utiliser un entier.
C'est très rare que vous trouverez une vraie clé naturelle. Ce qui semble unique aujourd'hui peut changer demain sur la base des besoins / lois de l'entreprise.
C'est ce que les séquences sont conçues pour résoudre. Créez un objet qui peut être augmenté atomique par insert. Dans certains DBS incrémentés automatiquement entier et dans d'autres, c'est un objet de séquence, mais l'idée est la même, c'est-à-dire créer une clé qui ne peut pas entrer en conflit et est unique.
aussi uuids comme une pièce d'identité va bien et je l'ai utilisé avant pour des raisons spéciales. Pourquoi le hasard "vous désactive"? Il n'y a pratiquement aucune chance de conflit.
À la fin de la journée, la manière de vérifier si un identifiant d'utilisateur donné est valide est le système lui-même. C'est-à-dire que votre système est la source faisant autorité pour ces identificateurs. Est 555-45-9999 un SSN valide? La seule façon de savoir à coup sûr est d'avoir la sécurité sociale le chercher et de le faire correspondre au nom de la personne affirmant avoir ce numéro. Bien sûr, nous pouvons utiliser le schéma d'identifiant SSN pour passer une hypothèse préliminaire quant à savoir s'il est valide. Cependant, seule une recherche dans leur système nous le dira. Le besoin de chiffres de contrôle se poserait dans des systèmes hautement distribués où, par exemple, vous voudrez peut-être permettre aux autres personnes de générer des chiffres honorés par votre système (par exemple, des sociétés d'expédition qui permettent aux clients de générer leurs propres numéros de suivi). Comme il s'agit de votre système qui va générer les identifiants de manière automatisée, le meilleur chiffre de contrôle est pour vous d'aider, de manière rudimentaire, avec validation sur la saisie de données ou les recherches.
Sur la base de notre conversation ci-dessus dans les commentaires, je pose cela comme une réponse. Il semble que vous croyiez que d'avoir un identifiant unique aléatoire attribué à vos utilisateurs leur fournirait suffisamment de sécurité que vous pourriez renoncer à des méthodes d'authentification normales.
En tout cas, je suis confondu par vos comparaisons entre les données sécurisées et l'incrémentation automatique, des colonnes d'identité basées sur les entiers dans des tables d'utilisateur. Ces deux types de données ne devraient jamais être mélangés. Votre compagnie de carte de crédit ne doit pas utiliser de CCN comme clé primaire dans une table de base de données et le gouvernement ne doit pas utiliser votre nom ou SSN comme clé primaire dans ses tables de base de données.
Pourquoi devriez-vous (ou quiconque) authentifier les utilisateurs avec Même si vous avez mis en œuvre une UUID et généré un nombre aléatoire arbitraire, il est toujours juste que: un numéro
J'étais sur le point d'élargir mon post à cet effet. Un nombre, n'importe quel nombre, seul, n'est jamais suffisant pour déterminer la validité et l'authenticité à la personne à qui elle est associée.
Vous confondez la fonctionnalité de base de données interne avec des critères de recherche externes.
Les touches de substitution automatique d'incréments sont utiles pour une utilisation interne de l'application. Ne jamais passer ceux à l'utilisateur. Identifier les objets métier, qu'il s'agisse d'un utilisateur ou d'une facture, sont effectués avec des informations uniques sur l'objet, telles que SSN, CCN ou DOB. Utilisez autant d'informations que nécessaire pour identifier de manière unique l'objet.
Je recommande vivement que si vous devez fournir une valeur d'identification nouvellement inventée à chaque client, ce n'est pas le champ que vous associez toutes les tables de données client sur.
Cette réponse a le plus de sens pour moi. Merci.
Peut-être utile de revoir ce que certaines autres bases de données font pour exposer des ID.
Salesforce utilise les trois premiers caractères pour déterminer l'objet, puis les 12 suivants sont incrémentés sensibles à la casse.
Ainsi, un compte Salesforce commence 001 et un contact Salesforce commence 003.
Un compte Salesforce peut donc ressembler à un 001000246ABCABC de 15 chiffres. Mais les identifiants sensibles à la casse sont un problème d'Excel (tri, déduplication, etc.), la plupart des gens utilisent les ID de 18 chiffres de Salesforce qui sont sensibles à la casse. Il y a une formule standard pour les convertir de 15 à 18.
Stripe préfixe leurs identifiants avec CUS_ pour les clients ou PI_ pour les paiements. Ainsi, un client peut être CUS_ABCDABCD123456 (14 chiffres) mais un paiement peut être PI_0123456789ABCDEABCDE1234 (24 chiffres).
L'ID de Xero ressemble à ceci pour les contacts, ABCD1234-AB12-12AB-9902-ABCDEF123456.
QuickBooks Online a apporté la décision discutable d'exposer ses identifiants comme des entiers incrémentiels spécifiques à une entreprise. Donc, vos factures seront de 1, 2, 3, etc. Il s'agit également de problématique que chaque société QOA aura une ID de facturation de 1, faisant des collisions dans des bases de données inévitables si vous avez plusieurs données de sociétés QBO au même endroit.
Qu'en est-il des conseils de votre professeur vous ont amené à conclure que les entiers auto-incréments étaient inappropriés comme des identifiants uniques pour les données utilisateur?
Les entiers incrémentés automatiquement sont prévisibles et ne contiennent aucune forme de détection d'erreur. Tout au moins, je m'attendrais à une pratique d'identification «de qualité professionnelle» pour être quelque peu imprévisible et auto-identifiant. Par exemple, les numéros de carte de crédit ont un chiffre de contrôle, ce qui signifie que si une carte de crédit est incorrectement une carte de crédit, il n'y a qu'une chance de 1/10 que cela serait accepté. Ils sont également raisonnablement imprévisibles, un pirate informatique ne peut donc pas simplement taper des numéros de carte de crédit aléatoire dans Amazon et espère qu'il a même un numéro de carte de crédit valide. De même, un pirate informatique ne devrait pas blesser des attaques de dictionnaires à des UID prévisibles.
Je ne comprends pas votre comparaison ici. Je serais abasourdir si les sociétés de cartes de crédit utilisaient des numéros de carte de crédit réels comme ID de base de données, plutôt que de les stocker comme un attribut fortement sécurisé dans une table. Votre commentaire implique que la connaissance d'un identifiant serait une sorte de backdoor dans la base de données. L'authentification de quelque sorte devrait être la défense contre l'accès non autorisé à des données, et non la connaissance des valeurs de base de données aléatoires.
@ Dragontamer5788 - Je soumets que, dans ce jour et que le chiffre de contrôle sur un CC n'est pas aussi utile qu'une requête contre la société CC avec la valeur Numéro, Nom et CCV pour vérifier son propriétaire. La seule façon de savoir si le CC est valide consiste à interroger la source faisant autorité.
@THOMAS: Je n'implique pas que les chiffres CC sont validés par leur chiffre de contrôle seul. Cependant, il semble être un avantage avec peu de coûts. Les chiffres de contrôle peuvent être facilement implémentés dans JavaScript efficace et l'utilisateur peut immédiatement savoir qu'il a commis une erreur en tapant. IE: Les chiffres de contrôle sont là pour la convivialité et non pour la sécurité.
@ Dragontamer5788 - Je ne suis pas d'accord sur le fait qu'il y a peu de coûts particulièrement renouvelables. Il y a des efforts impliqués dans la dérive de l'algorithme de contrôle de contrôle et le maintiennent face à une modification de l'identifiant. Les cartes de crédit sont fortement distribuées dans la mesure où de nombreuses entreprises peuvent générer des valeurs (semblable à l'exemple de la société d'expédition que j'ai donnée dans mon poste). Si le système étant construit sera toujours la seule source faisant autorité, puis un chiffre de contrôle fournit presque aucun avantage imo.