C'est une question assez générale, mais j'aimerais savoir sur quoi utilisez-vous dans la détermination de la clé primaire de la table. Les exemples fournis avec vous raisonnement sont hautement désirés.
J'ai remarqué que de nombreux programmeurs ajoutent une colonne ID et l'utiliser comme clé primaire. Je pense que c'est imparfait du point de vue design, comme ID dans ce cas n'a rien à voir avec la table.
14 Réponses :
Le rôle d'une clé primaire consiste à identifier de manière unique chaque ligne de votre table. Si aucune colonne ou ensemble de colonnes ne correspond à cette exigence, une colonne contenant une pièce d'identité unique est souvent ajoutée en tant que clé primaire.
Je ne suis pas d'accord avec votre commentaire sur les programmeurs ajoutant un identifiant qui n'a rien à voir avec les données de la table. Lorsque vous devez relier les données sur plusieurs tables, un identifiant concis est plus facile à utiliser qu'une clé composée.
La touche ID est généralement appelée clé de substitution: en.wikipedia.org/wiki / Subsharge_key
Si une table n'a pas de colonne ou de jeu de colonnes qui identifient de manière unique une ligne donnée, le modèle de données est presque certainement défectueux. Certes, une clé de substitution est souvent plus pratique qu'une clé composée (en particulier lors de l'interaction avec des outils ORM), mais il s'agit d'un complément, et non d'un substitut à une clé d'entreprise correctement identifiée. Notez que la clé Business peut être une séquence incrémentée monotique par exemple. Numéro de commande.
La clé principale doit toujours être un entier d'incrémentation automatique qui n'est pas liée à vos données.
édité pour ajouter que les GUDR sont bien aussi. L'important est que la clé ne décrit pas vos données, donc si vos données changent, votre PK ne le fait pas. Toujours utiliser un champ d'identification.
Considérez que vous utilisez un courrier électronique comme clé principale, puis l'utilisateur modifie son adresse e-mail. Vous devez ensuite cascade qui passe à chaque table jointe. Utiliser des données réelles comme votre PK n'a pas de sens.
Ceci est fortement discutable. Certaines personnes pensent qu'ils devraient être des GUDS. Certaines personnes pensent qu'ils devraient être basées sur les données de la DB et ne pas être une colonne séparée. Vous aurez besoin d'un raisonnement derrière votre affirmation pour obtenir beaucoup de soutien.
@Matt tu plaisantes ou est-ce flamme?
-1; beaucoup trop large d'une règle. Si les données ont intrinsèquement des informations d'identification de manière unique, il peut être utilisé; Si vous êtes préoccupé par la réplication ou le déplacement des données, une ligne de ligne peut être une très bonne idée. Un entier d'auto-incrémentation automatique est simple et bon pour la performance mais ne va pas bien et n'est pas une balle d'argent.
Les clés primaires n'ont pas besoin d'être des touches de substitution, les touches de substitution sont utiles, mais vous devriez également être en mesure de décrire la clé naturelle des données. Si vous ajoutez une clé de substitution sans comprendre quelle est la clé naturelle (souvent si vous utilisez un substitut, le naturel comprend une date / horodatage), vous aurez des problèmes de décider ce qui se passe dans la table.
Ok bien, utilisez un guid au lieu d'un int. Le fait est que cela ne devrait pas être basé sur vos données. Considérez que vous utilisez un courrier électronique comme clé principale, puis l'utilisateur modifie son adresse e-mail. Vous devez ensuite cascade qui passe à chaque table jointe. Utiliser des données réelles comme votre PK n'a pas de sens.
Matt: Votre commentaire a un bon point qui soutient votre réponse ... Donc, éditez votre réponse et mettez-la là-bas, et vous aurez plus de chances d'augmenter votre soutien.
Couples Hollywood: Les relations sont plus difficiles que vous ne le pensez ... une de mes favoris.
Une touche doit être une colonne où chaque entrée est garantie d'être unique. Les exemples peuvent être des choses comme un numéro d'assurance sociale ou un numéro de permis de conduire. En théorie, vous pouvez attacher plusieurs colonnes ensemble dans une clé composée. Donc, peut-être que le nom et la journée de naissance peuvent être uniques ensemble afin qu'ils puissent être une clé. Cependant, dans la pratique, personne ne fait cela parce que les tables croisées sont une douleur. La meilleure solution consiste généralement à ajouter une valeur automatique de la valeur ou de la colonne GUID.
Vous choisissez tout ce que vous savez être une valeur unique, de préférence quelque chose de numérique tel qu'un identifiant client ou un numéro de compte. Éloignez-vous des clés à base de cordes si possible. Si rien d'autre, utilisez une valeur GUID ou un entier d'incrémentation automatique.
+1 pour les GUID. Traditionnellement, j'ai toujours utilisé un entier d'incrémentation pour l'identifiant de clé, mais j'ai trouvé la méthode du GUID beaucoup plus facile. Cela peut ne pas être le cas pour tout le monde, mais j'ai sauté un navire de nombres entiers aux guidons :)
Bon point mais cela ne ferait pas mal de mentionner pourquoi. Une recherche numérique est plus rapide et des cordes, en particulier celles à différentes longueurs, apportent des index plus lents en général. Lisez High Performance MySQL pour une explication détaillée. Voici un excellent regard avancé sur certains problèmes d'indexation: xaprb.com/blog/2009/02/12/...
@joe ne doit pas mentionner les clés principales de chaîne Utilisez une tonne d'espace à InnoDB.
Vous avez bien sûr bien sûr google à propos de cette première, non? Je vois que les premiers résultats qui apparaissent pour moi avec la définition appropriée d'une clé primaire contiennent également des exemples.
Une clé primaire ne doit pas nécessairement être une colonne unique, mais peut également être une combinaison de colonnes. Comme
0 commentaires
Eh bien, dans l'un des systèmes que nous utilisons (et j'ai conçus), chaque utilisateur a une clé primaire incrémentée automatiquement comme identifiant. Les autres tableaux liés à cet utilisateur particulier utilisent leur identifiant comme clé primaire (bien que non pas automatiquement incrémentés) également, il a donc de sens si utilisé si utilisé correctement.
En théorie Tout champ unique pourrait être utilisé (par exemple le numéro de sécurité sociale, l'URL, etc.), mais dans la pratique, je ne pense pas qu'il y ait un gros inconvénient à utiliser un ID généré automatiquement. Par exemple, une erreur farfelu rend la duplication de SSN pourrait être désastreuse à vos données.
Mon processus de pensée dans la détermination d'une clé primaire va comme ça.
"Un enregistrement dans cette table représentera ..."
"Pour une valeur distincte de col x, col y, col z .. Il ne devrait y avoir qu'une rangée dans la table", quels sont les cols x y et z? "
hmm Cette table stocke des informations sur différents types de voitures, si le fabricant_name sera la clé? Non, je peux avoir de nombreuses lignes identifiant différents modèles de voiture du même fabricant. Hmm si le nom du fabricant et le nom_drogramme sont la clé? Non, je veux avoir des lignes différentes avec le même nom de fabrication et model_name, mais différentes années de publication dans la table en même temps. Ok qu'en est-il du "Nom de fabricant", "Model_Name" et "Livraison_Year".
Est-il possible pour moi d'avoir deux rangées avec le même fabricant_name, model_name et version_year en même temps? Hmmm no. Cela n'aurait pas de sens, ils seraient le même modèle de voiture et je veux seulement 1 enregistrement par modèle de voiture. Génial, c'est la clé.
Un enregistrement dans ce tableau représentera un modèle particulier d'une année donnée à partir d'un fabricant particulier. Je décide de cela lorsque je crée la table, c'est pourquoi j'ai créé la table, si vous ne pouvez pas décrire ce qui se passe dans la table en termes d'identification de la clé que vous ne comprenez pas vraiment pourquoi vous le créez.
changements horribles au fil du temps !!! (touches de substitution, clé naturelle, variation lente des dimensions)
AH mais les informations que je stocke sur un modèle de voiture en particulier (d'une année de fabrication et de publication particulière) peuvent changer. Au départ, on m'a dit que cela avait deux portes, maintenant je trouve que cela a quatre, je veux avoir cette information correcte dans ma table, mais je ne perdez pas l'ancien dossier, car les gens l'ont signalé et que je dois pouvoir reproduire leurs anciens résultats. .
OK, je vais ajouter une nouvelle colonne "Model_id" et en faire la clé primaire de la table afin que je puisse stocker plusieurs enregistrements avec le même nom de modèle, le nom du fabricant et l'année de publication. J'ajouterai également un mode valid_from et valid_to horodatage.
Ceci peut bien fonctionner et, en effet, avec mes modifications, la clé primaire de la table est maintenant modèle_id, une clé de substitution. Mais la clé naturelle, la clé de l'entreprise, la clé «à tout moment», est toujours modèle_name, fabricant et publié_year, et je ne peux pas perdre de vue de cela.
Une clé de substitution est unique pour chaque ligne, par définition! Une clé de substitution facilite la manipulation des données parfois, en particulier des données qui changent au fil du temps. Mais une clé de substitution ne remplace en aucune manière une clé primaire naturelle, vous devez toujours savoir ce que le «grain» de la table est.
Si nous disions que chaque personne en Australie sera attribuée à Stack_overflow_user_id Que ferions-nous quand Jeff et Joel commençaient à donner Stack_overflow_user_id'id'id'id'id'id'ID's to Dogs and Cats et plusieurs identifiants vers les mêmes personnes ??
Nous dirions: "Hey Jeff et Joel, ne donnent que 1 id par premier_name, last_name, date_of_birth et place_of_birth!". *
Nous devons connaître la clé naturelle ou nous pouvons donner n'importe quoi une clé de substitution!
(* Qu'en est-il des gens où tout cela sont les mêmes? N'avons-nous pas besoin d'un numéro de passeport ou d'une sorte de substitution de substitution? En pratique, un substitut est agréable et propre, mais où est-il originaire? À l'origine, il est venu d'un naturel clé.)
Cette réponse pourrait utiliser un peu de nettoyage, mais est facile +1 pour expliquer le processus de réflexion derrière le concept de touches naturelles de plusieurs colonnes.
Lorsque j'utilise des touches de substitution, il me semble que la performance augmente. J'utilise habituellement INT ID pour la performance.
pense à cela comme un identifiant unique possible (colonnes simples ou multiples) pour vos enregistrements.
Pensez à des empreintes de doigts. Pensez-vous qu'ils sont uniques à un individu? Cela n'a pas encore été prouvé, mais cela ressemble vraiment à un identifiant unique décent jusqu'à ce que la population soit si grande que la redondance se glisse. À l'heure actuelle, c'est comme une clé primaire pour les enregistrements qui vous identifient. [1 colonne]
Dans le cas où notre population explose et que les empreintes de doigts commencent à montrer leurs faiblesses, nous pouvons combiner des empreintes de doigts et des analyses d'iris pour être une clé primaire beaucoup plus forte. [2 colonnes]
La clé principale est généralement unique par conception, telle qu'un numéro d'identification fourni à l'instanciation de l'enregistrement dans notre base de données.
Au moins, j'espère que cela aide avec le concept.
Chaque donnée nécessaire pour identifier de manière unique votre entrée doit être votre identifiant de table. Si aucune de ces données n'existe, vous devez en créer un (le plus souvent, un numéro d'exécution est utilisé).
Je ne suis pas d'accord sur votre point que tous les identités devraient avoir quelque chose à voir avec la table, car parfois, il ne suffit pas d'identifier de manière unique l'enregistrement. De plus, vous devez utiliser plusieurs identifiants qui sont beaucoup plus difficiles à travailler avec un simple numéro d'exécution comme ID.
Les clés primaires sont relativement simples pour les tables simples, mais une fois que vos entrées sont réparties sur plusieurs tables, les choses peuvent devenir sales, en particulier avec de nombreuses connexions. Travailler avec des clés étrangères doit également être réfléchi avant de les mettre en œuvre.
Si vous voulez travailler professionnellement avec des bases de données (ou que vous voulez le faire par le livre), il serait préférable de vous familiariser avec EDIT: Langue de modélisation unifiée devrait vous aider à déterminer ce qu'il faut utiliser comme clé primaire
Utilisez des clés naturelles partout où elles travaillent et peuvent être approuvées. Si vous analysez votre sujet dans des entités et des relations entre les entités (ER), vous devez proposer des clés qui identifient les entités dans les données elles-mêmes. S'il existe une entité dont l'identité est confondue dans les données elles-mêmes, inventez une clé artificielle (généralement appelée clé de substitution). Inventer une clé est un dernier recours.
Lorsque vous allez à la construction de tables, certaines tables décrivent des entités et d'autres décrivent des relations. Les tables d'entité ont la même clé que l'entité. Les tables de relation reçoivent une clé composée avec un composant pour chaque entité qui participe à la relation. Certaines relations ne feront pas une table de leur propre (beaucoup à une). Au lieu de cela, ils seront représentés en ajoutant des clés étrangères aux tables existantes. Ils n'auront donc pas besoin d'une clé primaire de leur propre.
Cela vous ralentira un peu par rapport à l'utilisation de champs d'identité inventés pour chaque table. Mais cela entraînera une meilleure gestion des données, ce qui entraînera une meilleure donnée.
Bienvenue à l'arrière, à la partie 1 304 052 dans la grande clé naturelle vs. Débat clé de port de substitution!
C'est une grande question générale. La réponse gagnante devrait être assez longue, décrivant à la fois la clé primaire, et les diverses rationnelles ont pour les vouloir dans des champs séparés ou non, etc.
Merci, je commence par la programmation et la conception de la DB, et à la recherche de conseils du meilleur
@enigma: ne pas être trop dur, mais à la recherche de conseils du meilleur lorsque vous commencez pas, ne va pas aider beaucoup. Si j'apprends à conduire, je veux que Mario Andretti m'apprendais? Non, je vais franchir une épave en essayant de le mettre en voiture :)
@enigma, vous voulez savoir ce que "le meilleur est", bien le voici: cela dépend de nombreux facteurs. différentes situations nécessitent différentes configurations de clés. Si c'était facile, il y aurait un moyen simple de les choisir. Cela dit, être capable d'identifier, d'évaluer et de donner la priorité à ces facteurs est où l'expérience et le savoir-santé entrent en jeu. La conception de la base de données est un art autant qu'une science.
@Yoooder bon point, mais c'était seulement signifié comme un compliment :)
Enigma: Le mieux d'accord: Utilisez un ID pour identifier vos données: p