Numéro VS Varchar (2) Clés primaires

Question

Je suis maintenant à ce point de mon projet que j'ai besoin de concevoir ma base de données (Oracle). Habituellement, pour le statut et les pays tables, je ne pas utiliser une clé primaire numérique, par exemple

STATUS (max 6) 
AC --> Active 
DE --> Deleted 

COUNTRIES (total 30) 
UK --> United Kingdom 
IT --> Italy 
GR --> Greece 

Ces tables sont statiques, pas mis à jour par l'application et il est pas prévu être le changement dans l'avenir donc il est aucune chance d'avoir des problèmes de mise à jour dans les tables qui utiliseront ces valeurs comme clés étrangères.

Le tableau principal de l'application utilisera le statut et le pays (plus d'une fois par exemple, pays d'origine, pays de destination) et il est prévu que 600000 lignes seront ajoutées par an

Donc ma question est, ce que ces VARCHAR (2) les clés auront un impact sur la performance lors de l'interrogation de la jointure de 3 tables. Le premier sera-t-il significativement plus lent que le second?

SELECT m.*, 
     s.status_name, 
     c.country_name 
    FROM main m, status s, countries c 
WHERE m.status_cd = s.status_cd 
    AND m.country_cd = c.country_cd 
    AND m.status_cd = 'AC' 
    AND m.country_cd = 'UK' 

SELECT m.*, 
     s.status_name, 
     c.country_name 
    FROM main m, status s, countries c 
WHERE m.status_cd = s.status_cd 
    AND m.country_cd = c.country_cd 
    AND m.status_cd = 1 
    AND m.country_cd = 2 

---

Clarification:

état est non binaire ("max 6" à côté du nom de la table). Les valeurs seront probablement:

* active 
* deleted 
* draft 
* send 
* replaced 

et nous devons afficher les valeurs décodées à l'utilisateur, donc nous avons besoin des noms.

Answer 1

Si 'status' est (et sera toujours?) Un champ binaire actif/supprimé, pourquoi s'embêter avec la table? Il semble que la normalisation soit poussée à un extrême impossible.

Il serait certainement plus rapide, sans parler de plus facile, d'utiliser simplement un tinyint (1) terrain et enregistrer l'état actif/supprimé en tant que 1 ou 0.

Ceci élimine un de vos complètement les jointures ce qui doit être une bonne chose.

Answer 2

Consultez ce link. Bottom line est il n'y a pas beaucoup de différence de performance entre varchar et num. Donc, vous devriez aller pour qui a toujours du sens pour la colonne. Ici, le varchar semble avoir plus de sens.

Answer 3

Peu importe la méthode que vous choisissez dans ce cas. L'important est d'utiliser le même type dans toute la base de données et d'être cohérent dans votre convention d'identification.

Answer 4

Les tables d'état et de pays sont si petites qu'elles vont être résidentes en mémoire dans la pratique, qu'elles soient formellement déclarées comme telles ou non. En effet, sauf qu'une clé étrangère nécessite normalement un index sur le champ clé primaire référencée, vous pourriez être tenté de ne pas vous soucier des index sur les tables. La différence de performance entre les jointures de types différents va être négligeable, et le code numérique sera plutôt plus lent puisqu'il y a plus de données à stocker (mais elles sont si petites qu'elles sont négligeables, encore).

Alors, allez avec les codes naturels. Tout le reste à part, le SQL dans le premier exemple est plus clair; le 'UK' et 'AC' sont beaucoup plus significatifs que 1 et 2.

Dans un SGBD non-Oracle, vous utiliserez probablement CHAR (2) pour les valeurs de code d'état et de pays.Les utilisateurs d'Oracle ont tendance à utiliser VARCHAR2 pour tout. Je ne suis pas sûr qu'il y ait une pénalité pour l'utilisation d'une colonne CHAR (2) à la place, d'autant plus que les valeurs des colonnes sont de longueur fixe. (Sous Informix, par exemple, un champ VARCHAR (2) - un champ de deux caractères maximum - serait stocké sous forme de 3 octets, une longueur (toujours 2 dans votre cas) et les 2 octets de données.)