performance - Número VS Varchar(2) Teclas principales

primary-key numbers

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 países no utilizo una clave primaria numérica, por ejemplo

STATUS (max 6)
AC --> Active
DE --> Deleted
COUNTRIES (total 30)
UK --> United Kingdom
IT --> Italy
GR --> Greece

Estas tablas son estáticas, no se actualizan a través de la aplicación y no está previsto que se modifiquen en el futuro, por lo que no hay posibilidad de tener problemas de actualización en las tablas que utilizarán estos valores como claves externas.

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

Entonces mi pregunta es, ¿estas claves VARCHAR (2) tendrán un impacto en el rendimiento al consultar la combinación de las 3 tablas allí? ¿El primero será 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:

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

* active
* deleted
* draft
* send
* replaced

y necesitamos mostrar los valores decodificados para el usuario, entonces necesitamos los nombres.

Answer 1

Mira este enlace . 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 2

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 3

Si ''status'' 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.

Sin duda sería más rápido, sin mencionar más fácil, simplemente usar un campo tinyint (1) y registrar el estado activo / borrado como 1 o 0.

Esto elimina por completo una de tus combinaciones, lo que tiene que ser algo bueno.

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 declarados como tales 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 será insignificante, y el código numérico, en todo caso, será más lento ya que hay ''más'' datos para almacenar (pero todo 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; el ''Reino Unido'' y ''AC'' son mucho más significativos que 1 y 2.

En DBMS que no son de 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)