¿Cómo debo representar un tipo enumerado en una base de datos relacional?

Estoy trabajando en el desarrollo de una base de datos relacional que rastrea las transacciones que ocurren en un dispositivo en el que estoy trabajando para mi empresa. Existen diferentes tipos de transacciones que pueden ocurrir en el dispositivo, por lo que tenemos un campo "trans_type" en una de nuestras tablas de registros principales. Mi grupo ha decidido convertir el tipo de este campo en un entero y tratarlo como un tipo enumerado. Mi intuición me dice que sería una mejor idea hacer de este campo una cadena para que los datos de nuestra base de datos sean más legibles y utilizables. Mis compañeros de trabajo parecen estar preocupados de que esto pueda causar más problemas de lo que vale. Las comparaciones de cadenas son demasiado costosas y la posibilidad de errores tipográficos es una barrera demasiado grande.

Entonces, en su opinión, cuando se trata de un campo en una base de datos relacional que es esencialmente un valor enumerado, ¿es una mejor decisión de diseño hacer de este campo un entero o una cadena? ¿O hay alguna otra alternativa que he pasado por alto?

Nota: los tipos enumerados explícitos no son compatibles con la base de datos que estamos utilizando. Y el software que estamos desarrollando que interactuará con esta base de datos está escrito en C ++.

Los tipos enumerados deben ser una tabla separada en su base de datos que tenga un número de identificación y un nombre de cadena y cualquier otra columna que pueda resultarle útil. Entonces cada tipo existe como una fila en esta tabla. Luego, en su tabla, está registrando las transacciones, el campo "trans_Type" debería ser una clave externa a la clave de esa tabla de referencia. Esta es una práctica estándar en la normalización de bases de datos.

De esta manera, ha almacenado una cadena de nombre oficial, puede usar comparaciones de números para el rendimiento y tener integridad referencial de que cada transacción tiene un tipo válido.

Una práctica común es crear una trans_typestabla y luego hacer que su tabla principal haga referencia a ella con una clave externa llamada trans_type_id. Esto garantiza que sus registros solo hagan referencia a tipos enumerados válidos.

Ejemplo:

trans_type
----------
  carné de identidad
  nombre

actas
------------
  carné de identidad
  trans_date
  detalles
  trans_type_id (FK a trans_type.id)

Datos de ejemplo:

trans_type

ID | NOMBRE
----------
1 | ENVIAR
2 | CANCELAR


actas

ID | trans_date | trans_type_id
---------------------------------
1 | 2012-12-31 | 1
2 | 2013-01-09 | 2

Si los valores ingresan a la base de datos como enteros, guárdelos de esa manera. No es necesario poner la sobrecarga de convertir a cadenas mientras escribe en la base de datos. Siempre puede relacionarse con una tabla de búsqueda con los valores de cadena / texto (Más Normalizado).

Esto tiene la ventaja adicional de actualizar el valor de la cadena en una sola ubicación en lugar de ejecutar algún tipo de rutina de actualización. En lugar de 1 = 'Rojo' podría ser igual a 'Realmente rojo'

Esto no es ideal para informar el rendimiento en comparación con solo necesitar una tabla con valores de cadena (desnormalizados). Un índice en este campo haría que el rendimiento sea lo suficientemente bueno.

La mayoría de los RDBMS permitirán suficiente potencia. Aunque su idea de poder "leer" la tabla en su forma de datos simple, unirse a una tabla no es gran cosa. Solo tiene la costumbre de usar una vista o algún objeto similar.

Tengo que estar en desacuerdo con las otras respuestas a esta pregunta que defienden el enfoque de la tabla de enumeración por separado.

Sin embargo, ciertamente estoy a favor de no repetir lo que ya se ha dicho, así que simplemente me referiré a la respuesta aceptada (más o menos) a la misma pregunta sobre Stack Overflow: /programming//a/229919 / 114626