Número VS Varchar (2) Teclas principales

Question

Ahora estoy en este punto de mi proyecto que necesito diseñar mi base de datos (Oracle). Por lo general, para las tablas de estado y de los países que no utilizan una clave primaria numérico, por ejemplo

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

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

Estas tablas son estáticos, no se actualizan mediante la aplicación y no es previsto que haber un cambio en el futuro, por lo que hay no hay posibilidad de tener problemas de actualización en tablas que usarán estos valores como claves foráneas.

La mesa principal de la aplicación utilizará el estado y el país (más de una vez por ejemplo, país de origen, el país de destino) y se prevé que 600.000 filas se añadirán al año

Así que mi pregunta es, ¿estos VARCHAR (2) las claves tendrán un impacto en el rendimiento al consultar la combinación de las 3 tablas existentes. ¿Será el primero significativamente más lento que el segundo?

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 

---

Aclaración:

de estado no es binario ("max 6" al lado del nombre de la tabla). Los valores probablemente serán:

* active 
* deleted 
* draft 
* send 
* replaced 

y tenemos que mostrar los valores decodificados al usuario, por lo que necesitamos los nombres.

Answer 1

Si el 'estado' es (¿y siempre será?) Un campo binario activo/eliminado, por qué molestarse con la tabla en absoluto. Parece que la normalización es llevada a un extremo poco práctico.

Sería ciertamente ser más rápido, por no mencionar más fácil, simplemente usar un (1) Campo tinyint y registrar el estado activo/borrado como 1 ó 0.

Esto elimina uno de sus uniones por completo que tiene que ser algo bueno.

Answer 2

Echa un vistazo a este link. En pocas palabras, no hay mucha diferencia de rendimiento entre varchar y num. Entonces deberías ir por lo que tenga sentido para la columna. Aquí, el varchar parece tener más sentido.

Answer 3

No importa qué método elija en este caso. La parte importante es usar el mismo tipo en toda la base de datos y ser coherente en su convención de identificación.

Answer 4

Tanto el estado como las tablas de países son tan pequeños que en la práctica van a residir en la memoria, ya sea formalmente declarado como tal o no. De hecho, salvo que una clave externa normalmente requiere un índice en el campo de la clave principal referenciada, es posible que tenga la tentación de no molestarse con ningún índice en las tablas.

La diferencia de rendimiento entre las uniones con diferentes tipos va a ser insignificante, y el código numérico, si acaso, será más lento ya que hay 'más' datos para almacenar (pero es tan pequeño que es insignificante, de nuevo).

Por lo tanto, vaya con los códigos naturales. Aparte de todo lo demás, el SQL en el primer ejemplo es más claro; 'UK' y 'AC' son mucho más significativos que 1 y 2.

En DBMS no Oracle, probablemente use CHAR (2) para los valores de estado y de código de país.Los usuarios de Oracle tienden a usar VARCHAR2 para todo; No estoy seguro si hay una penalización por usar una columna CHAR (2) en su lugar, especialmente dado que los valores de la columna son de longitud fija. (En Informix, por ejemplo, un campo VARCHAR (2) - un campo de hasta dos caracteres - almacenaría como 3 bytes, una longitud (siempre 2 en su caso) y los 2 bytes de datos. Por el contrario, un CHAR (2)) el campo ocuparía solo 2 bytes.)