Tactique de normalisation SQL Server: varchar vs int Identity

Question

Je me demande simplement quelle est la solution optimale ici.

Disons que j'ai une base de données normalisée. La clé primaire de tout le système est un varchar. Ce que je me demande, est-ce que je devrais relier ce varchar à un int de normalisation ou le laisser? C’est plus simple de partir en varchar, mais c’est peut-être plus optimal

Par exemple, je peux avoir

People
======================
name      varchar(10)   
DoB       DateTime    
Height    int  

Phone_Number
======================
name      varchar(10)   
number    varchar(15)

Ou je pourrais avoir

People
======================
id        int Identity   
name      varchar(10)   
DoB       DateTime  
Height    int  

Phone_Number
======================
id        int   
number    varchar(15)  

Ajoutez plusieurs autres relations un à plusieurs, bien sûr.

Qu'en pensez-vous tous? Quel est le meilleur et pourquoi?

Answer 1

Pouvez-vous vraiment utiliser des noms comme clés primaires? N’y at-il pas un risque élevé que plusieurs personnes portent le même nom?

Si vous êtes vraiment chanceux de pouvoir utiliser votre attribut name en tant que clé primaire, utilisez-le. Souvent, cependant, vous devrez inventer quelque chose, comme un client_id, etc.

Et enfin: "NAME" est un mot réservé dans au moins un SGBD, pensez donc à utiliser autre chose, par ex. nom complet.

Answer 2

Je pense que la majorité des personnes qui ont développé des applications de bases de données de taille réelle dans le monde réel vous diront que les clés de substitution sont la seule solution réaliste.
Je sais que la communauté universitaire ne sera pas d’accord, mais c’est la différence entre pureté théorique et praticité.

Toute requête de taille raisonnable qui doit faire des jointures entre des tables qui utilisent des clés non substituables, certaines tables ayant des clés primaires composites, devient rapidement non maintenable.

Answer 3

L'utilisation de n'importe quel type de données non synthétiques (c'est-à-dire n'importe quoi de l'utilisateur, par opposition à celles générées par l'application), car une PK pose problème; vous devez vous préoccuper des différences de culture / localisation, de la sensibilité à la casse (et d'autres problèmes en fonction du classement de la base de données), peuvent entraîner des problèmes de données si / lorsque les données saisies par l'utilisateur changent, etc.

Utiliser des données non générées par l'utilisateur (les GUID séquentiels (ou non séquentiels si votre base de données ne les prend pas en charge ou si vous ne vous souciez pas des fractionnements de page) ou des identités internes (si vous n'avez pas besoin de GUID)) beaucoup plus facile et beaucoup plus sûr.

En ce qui concerne les données en double: je ne vois pas comment l’utilisation de clés non synthétiques vous protège de cela. Vous avez toujours des problèmes où l'utilisateur entre " Bob Smith " au lieu de "Bob K. Smith" ou " Smith, Bob " ou "bob smith" etc. La gestion de la duplication est nécessaire (et pratiquement identique), que votre clé soit synthétique ou non synthétique, et les clés non synthétiques ont une foule d'autres problèmes potentiels que les clés synthétiques évitent parfaitement.

De nombreux projets n’ont pas à s’inquiéter pour cela (par exemple, les choix de classement très limités en évitent beaucoup), mais en général, je préfère les clés synthétiques. Cela ne veut pas dire que vous ne pouvez pas réussir avec des clés organiques, vous pouvez le faire, mais pour de nombreux projets, ce n’est pas le meilleur choix.

Answer 4

Je pense que si votre VARCHAR était plus grand, vous remarqueriez que vous dupliquez pas mal de données dans la base de données. Tandis que si vous utilisez une colonne d’identification numérique, vous ne dupliquez pas à peu près la même quantité de données lorsque vous ajoutez des colonnes de clé étrangère à d’autres tables.

De plus, les données textuelles sont une douleur royale en termes de comparaison, votre vie est beaucoup plus facile lorsque vous faites WHERE id = id_utilisateur ou WHERE name LIKE inputname ( ou quelque chose de similaire).

Answer 5

Si le " nom " champ est vraiment approprié en tant que clé primaire, alors faites-le. La base de données ne sera pas normalisée en créant une clé de substitution dans ce cas. Vous obtiendrez des doublons pour les clés étrangères, mais ce n'est pas un problème de normalisation, car la contrainte FK garantit l'intégrité des chaînes comme elle le ferait pour les clés de substitution.

Cependant, vous n'expliquez pas ce que le "nom" est. En pratique, il est très rare qu'une chaîne soit appropriée en tant que clé primaire. S'il s'agit du nom d'une personne, cela ne fonctionnera pas comme un PK, car plusieurs personnes peuvent avoir le même nom, les personnes peuvent changer de nom, etc.

.

Answer 6

Une chose que les autres ne semblent pas avoir mentionnée, c'est que les jointures sur les champs int ont tendance à être plus performantes que les jointures sur les champs varchar.

Et j'utiliserais certainement toujours une clé de substitution avant d'utiliser des noms (de personnes ou d'entreprises) car ils ne sont jamais uniques au fil du temps. Dans notre base de données, par exemple, nous avons 164 noms avec plus de 100 instances du même nom. Cela montre clairement les dangers liés à l’utilisation du nom comme champ clé.

Answer 7

La question initiale n’est pas une question de normalisation. Si vous avez une base de données normalisée, comme vous l'avez indiqué, vous n'avez pas besoin de la modifier pour des raisons de normalisation.

Il y a vraiment deux problèmes dans votre question. Le premier est de savoir si ints ou varchars est préférable pour une utilisation en tant que clés primaires et clés étrangères. Deuxièmement, vous pouvez utiliser les clés naturelles données dans la définition du problème ou générer une clé synthétique (clé de substitution) pour remplacer la clé naturelle.

Les

ints sont un peu plus concis que varchars et un peu plus efficaces pour des opérations telles que le traitement des index. Mais la différence n'est pas écrasante. Vous ne devriez probablement pas prendre votre décision sur cette seule base.

La question de savoir si la clé naturelle fournie fonctionne réellement comme une clé naturelle est beaucoup plus importante. Le problème des doublons dans un " nom " la colonne n'est pas le seul problème. Il y a aussi le problème de ce qui se passe quand une personne change de nom. Ce problème ne figure probablement pas dans l'exemple que vous avez donné, mais il apparaît dans de nombreuses autres applications de base de données. Un exemple serait la transcription sur quatre ans de tous les cours suivis par un étudiant. Une femme peut se marier et changer de nom en quatre ans, et maintenant vous êtes coincée.

Vous devez laisser le nom inchangé, auquel cas il n’est plus conforme au monde réel, ou le mettre à jour de manière rétroactive dans tous les cours suivis par la personne, ce qui rend la base de données en désaccord avec les listes imprimées créées à l’époque.

Si vous choisissez une clé synthétique, vous devez maintenant décider si l'application va révéler ou non la valeur de la clé synthétique à la communauté des utilisateurs. C’est un autre ensemble de vers, qui dépasse le cadre de cette discussion.