Pourquoi devrais-je créer une colonne ID lorsque je peux en utiliser d'autres comme champs clés?
Duplicata possible:
Pourquoi utiliser un int comme clé primaire d'une table de recherche?
Jusqu'à présent, je suis habitué à créer une colonne ID pour chaque table et c'est pratique d'une manière qui ne me fait pas penser à la prise de décision sur les théories des clés primaires.
Le professeur de mon université a suggéré à la classe de créer des clés primaires à partir d'un ou plusieurs domaines qui constituent une seule information sur chaque colonne. Et oui, je veux avoir l'habitude d'appliquer clés naturelles au lieu de clés de substitution . Sur Wikipédia, les avantages et les inconvénients des clés de substitution sont répertoriés, je recommande strictement Cet article
J'ai vu des gens utiliser des champs ID entiers pour tout et personne ne juge cette méthode parce que
- il "semble" efficace
- un champ numérique est utilisé et il semble plus frais en raison de sa taille par ligne en mémoire
Je commence à penser qu'un champ d'identification supplémentaire crée simplement des données redondantes sans aucun avantage réel. Alors, pourquoi devrais-je créer une colonne ID lorsque je peux utiliser d'autres colonnes comme champs clés?
- Si votre champ ID est de 32 bits, cela équivaut déjà à 4 ASCII caractères déjà.
- Si votre champ Id est 64 bits entier, c'est 8 caractères chaîne donc cela n'économise pas vraiment beaucoup de mémoire (ce qui sous-entend ici est la mémoire utilisée à titre de comparaison. une colonne d'identification supplémentaire ajoute déjà à la mémoire utilisée (à la fois le disque dur et la RAM))
- Un champ ID supplémentaire double votre coût d'indexation car vous indexerez également un champ unique que vous pouvez utiliser comme clé primaire.
- Vous effectuez des jointures supplémentaires si vous avez besoin des données que vous auriez pu utiliser comme champ clé, par exemple, si vous avez stocké un ID utilisateur unique dans un article de blog , pour afficher le nom de l'auteur, vous effectuez une requête de jointure, si votre champ clé était le nom de l'auteur, vous n'avez pas besoin de vous joindre car vous stockez les données pertinentes dans la table de publication du blog. un champ de clé étrangère avec des données significatives réduit le besoin de sous-requête ou de jointure
- La création d'un champ d'ID supplémentaire "ajoute" à la charge de la mémoire, ce n'est pas un remplacement d'un champ de chaîne unique, vous ne remplacez pas un champ char-varchar par un entier, vous ajoutez un extra et il crée un flux de données supplémentaire . donc toute comparaison du magasin de données doit être faite entre "chaîne" et "chaîne int +". l'ajout d'un champ d'ID entier n'économise pas d'espace.
d'autre part
- attribuer des données de clé primaire qui tirent de la valeur de l'entrée de l'utilisateur, peut être problématique parce que les gens peuvent entrer, par exemple, leur numéro de sécurité sociale faux et la personne réelle qui veut s'inscrire ne pourra pas pour vous inscrire en raison de la politique unique. Cela peut être contourné en ajoutant un ou plusieurs chiffres supplémentaires au numéro d'origine.
Ressources supplémentaires:
Ma conclusion en lisant des articles est que je devrais utiliser des clés naturelles autant que possible au lieu de sauter la réflexion sur les clés naturelles et d'utiliser des clés de substitution à chaque fois, comme si c'était une référence.
1 - C'est plus rapide. Un JOIN sur un entier est beaucoup plus rapide qu'un JOIN sur un champ de chaîne ou une combinaison de champs. Il est plus efficace de comparer des entiers que des chaînes.
2 - C'est plus simple. Il est beaucoup plus facile de mapper des relations basées sur un seul champ numérique que sur une combinaison d'autres champs de différents types de données.
3 - C'est indépendant des données. Si vous correspondez sur le ID vous n'avez pas à vous soucier du changement de relation. Si vous faites correspondre un nom, que faites-vous si son nom change (c'est-à-dire le mariage)? Si vous faites correspondre une adresse, que se passe-t-il si quelqu'un déménage?
4 - C'est plus efficace Si vous effectuez un cluster sur un champ int (incrémentation automatique), vous réduisez la fragmentation et la taille globale de l'ensemble de données. Cela simplifie également les index nécessaires pour couvrir vos relations.
MODIFIER
Aux points spécifiques que vous venez d'ajouter:
1 et 2 - Il est toujours beaucoup plus rapide de comparer un int qu'une chaîne, sans tenir compte des considérations d'espace. Vous ignorez également la surcharge nécessaire pour stocker la longueur des champs de longueur variable (normalement 2 octets par champ par ligne).
3 - Si vous cluster sur le champ ID alors il n'ajoute rien de plus. Cela économise de l'espace car vous utilisez un identifiant de ligne plus efficace.
4 - Et puis quand cette personne change de nom d'utilisateur, tous vos liens se brisent.
5 - Vous ne savez vraiment pas de quoi vous parlez ici. Vous devez stocker les données, c'est correct, mais il est beaucoup plus efficace d'indexer et de JOIN sur l'int. Que sur une combinaison d'autres champs.
Parce que les gens ont appris par expérience que l'utilisation de ces champs entraîne des problèmes.
Je développe des applications de bases de données depuis 20 ans. Plus important encore, j'ai passé cinq ans à travailler avec des entrepôts de données. Au début, le choix d'un autre domaine semblait correct. Ensuite, nous avons trouvé des enregistrements en double, parfois des validations uniques manquaient, parfois (fréquemment) les utilisateurs avaient fourni des informations différentes qui devaient maintenant être fusionnées, ou autre chose, et la fusion et la gestion des enregistrements était un cauchemar.
Même (ou même particulièrement!) Lorsque l'identifiant "semble" unique, cela peut s'avérer faux. Par exemple: Numéro de sécurité sociale américain. Cela devrait être unique à une personne, non? Bien sûr, mais que se passe-t-il si certains enregistrements ont été saisis avec des SSN qui ont été mal tapés par les utilisateurs dans le passé? Il peut maintenant y avoir des problèmes de conflit avec de nouveaux numéros valides qui sont entrés pour de nouveaux enregistrements. Une note secondaire est que les clés primaires ne doivent également jamais être affichées car elles conduisent à des hypothèses de l'utilisateur à leur sujet et elles ne sont pas non plus adaptées au meilleur modèle de sécurité pour les URL de sites Web.
Considérez toujours - l'utilisateur va-t-il mettre cette URL en signet et s'attendre à ce qu'elle fonctionne à l'avenir?
Les gens ont donc appris:
N'utilisez pas de "clé de substitution" (par exemple SSN) comme clé primaire lorsque la mère porteuse a "n'importe quelle" valeur ou signification commerciale.
Utilisez plutôt une clé primaire unique et non dérivée des données d'application.
Si vous souhaitez rechercher vos données, vous voulez vraiment le faire en fonction d'un ou de plusieurs champs entiers. C'est pourquoi de nombreuses personnes utilisent un champ ID pour cela.
Mais si vous avez une table que vous utilisez pour une relation plusieurs-à-plusieurs, elle n'est pas vraiment nécessaire. Disons que vous avez les deux tableaux suivants:
Table news id entier titre varchar élément texte
Balises de table id nom entier varchar
Pour chaque élément de l'actualité, vous souhaitez ajouter une ou plusieurs balises, vous créez donc le tableau:
Tableau news_tags news_id entier tags_id entier
Dans ce cas, il n'est vraiment pas nécessaire de créer une colonne d'ID supplémentaire, car vous n'en aurez pas besoin du tout.
La plupart des gens utilisent par défaut un INT à incrémentation automatique pour leur clé primaire, car c'est le moyen le plus simple d'identifier la ligne, en particulier lorsque vous avez des relations entre des tables qui doivent être définies.
Si vous avez la chance de modéliser quelque chose qui a déjà un identifiant unique, je chercherais à l'utiliser pour la clé primaire (un exemple serait un VIN pour une voiture ou IMEI pour un téléphone portable).
Il existe également ce qu'on appelle des clés composées, essentiellement deux ou plusieurs champs de votre base de données identifiant de manière unique la ligne. La plupart des développeurs avec lesquels j'ai travaillé (y compris moi-même) ne l'utilisent généralement pas. Encore une fois, la principale raison du non est qu'il rend plus difficile la gestion des relations entre les tables.
Dans le monde naturel, les choses ne sont pas définies par un identifiant unique, mais par leur relation avec d'autres entités. Le champ id n'est vraiment qu'un artefact de bases de données relationnelles. C'est la base de tout le problème de mappage de relation d'objet (ORM).
Je me rends compte que c'est un cours et vous devez comprendre le contenu, mais n'oubliez pas qu'il existe sont d'autres façons de modéliser les données en dehors d'une base de données relationnelle. Le mouvement NoSQL en témoigne.
Si vous pouvez utiliser d'autres champs comme clés primaires, c'est bien. Cependant, puisque vous l'avez tagué sous [sql-server], je pourrai ajouter quelques informations ...
Si vous devez répliquer une table qui n'a jamais eu ni besoin d'une clé primaire, vous devrez en créer une. si vous aviez cette colonne id en place .. = simple comme bonjour
Les colonnes d'ID, en particulier celles qui sont
IDENTITYcolonnes sont également bonnes comme index (parfois) dans le sens où elles ne sont presque jamais mises à jour, et si vous ne supprimez pas de lignes de la table, vous diminuez la fragmentation d'index.Les colonnes d'identification ne doivent pas toujours être uniquement des colonnes d'identité. Vous pouvez stocker un date_id (pour certaines tables qu'il est logique de le faire) et s'il est unique (comme je l'ai dit .. par exemple, vous avez une table où une ligne = un jour), vous pouvez l'appliquer comme clé ou index
Lorsque vous n'avez pas de colonne create_date/entry_date et que vous devez vérifier les données dans l'ordre dans lequel elles ont été entrées. Le fait d'avoir une colonne ID comme identité rend cela possible.
Un ID peut également servir de clé étrangère.
Bien que les clés composées fonctionnent, une seule clé primaire peut parfois être plus facile à utiliser. Par exemple, lors de la suppression, il est très facile de distinguer une ligne particulière.
Il est également souvent plus efficace de rechercher sur une touche numérique.