Données statiques SQL/listes de recherche IDENTIFICATEUR

Question

En ce qui concerne la conception de tables de données statiques. Avoir des données statiques dans des tableaux comme montré:

• Devises (code, nom). Exemple de ligne: USD, Dollar des États-Unis
• Pays (code, nom). Exemple de ligne: DE, Allemagne
• XXXObjectType (code, nom, ... attributs supplémentaires)
• ...

est-il logique d'avoir une autre colonne (ENTIER) comme une clé primaire, afin de toutes les références de clé étrangère l'utiliseraient-elles?

solutions possibles:

1. Utilisez ENTIER supplémentaire PK et FK
2. code d'utilisation (généralement CHAR (N), où N est faible) PK et FK
3. Utilisez le code seulement si moins qu'une certaine taille ... Quelle taille?
4. Autres _______

Quelle serait votre suggestion? Pourquoi?

J'ai généralement utilisé les colonnes INT IDENTITY, mais très souvent le fait d'avoir le code court est assez bon pour montrer à l'utilisateur sur l'interface utilisateur, auquel cas la requête aurait un JOIN de moins.

Answer 1

Une ID INTENTION n'est absolument pas nécessaire ici. utilisez plutôt les mnémoniques à 2 ou 3 chiffres. Si vous avez une entité qui n'a pas de petite propriété unique, vous devriez alors envisager d'utiliser une clé synthétique. Mais les codes de devise et les codes de pays ne sont pas le moment de le faire.

J'ai déjà travaillé sur un système où quelqu'un avait une table d'années et chaque année avait un YearID. Et, fidèle à la forme, 2001 était l'année 3, et 2000 était l'année 4. Il a fait tout le reste dans le système, donc beaucoup plus difficile à comprendre et à interroger, et ce fut pour rien.

Answer 2

Si vous utilisez un ID INT ou un CHAR, l'intégrité référentielle est préservée dans les deux cas.
Un INT a une longueur de 4 octets, sa taille est donc égale à CHAR (4); si vous utilisez CHAR (x) où x < 4, votre clé CHAR sera plus courte qu'une INT; si vous utilisez CHAR (x) où x> 4, votre clé CHAR sera plus grande qu'une INT; pour les touches courtes habituellement est logique d'utiliser VARCHAR, car ce dernier a une surcharge de 2 octets. Quoi qu'il en soit, quand on parle de tables avec - disons - 500 enregistrements, l'overhead total d'un CHAR (5) sur une clé INT serait juste 500 octets, une valeur hilarante pour la base de données où certaines tables pourraient avoir des millions d'enregistrements. Considérant que les pays et les devises (par exemple) sont limités en nombre (quelques centaines, au plus), vous n'avez aucun gain réel en utilisant un ID INT au lieu d'un CHAR (4); de plus, une clé CHAR (4) peut être plus facile à mémoriser pour l'utilisateur final, et peut vous faciliter la vie lorsque vous devez déboguer/tester votre Sql et/ou vos données.
Par conséquent, bien que j'utilise habituellement une clé ID INT pour la plupart de mes tables, dans plusieurs circonstances, je choisis d'avoir un PK/FK fait de CHAR: pays, langues, devises sont parmi ces cas.