Como devo representar um tipo enumerado em um banco de dados relacional?

Estou trabalhando no desenvolvimento de um banco de dados relacional que rastreia as transações que ocorrem em um dispositivo em que estou trabalhando para minha empresa. Existem diferentes tipos de transações que podem ocorrer no dispositivo, portanto, temos um campo "trans_type" em uma de nossas principais tabelas de registros. Meu grupo decidiu tornar o tipo desse campo um número inteiro e tratá-lo como um tipo enumerado. Minha intuição me diz que seria uma idéia melhor transformar esse campo em uma string para que nossos dados do banco de dados fossem mais legíveis e utilizáveis. Meus colegas de trabalho parecem preocupados que isso cause mais problemas do que vale a pena. As comparações de strings são muito caras e a possibilidade de erros de digitação é uma barreira muito grande.

Portanto, na sua opinião, ao lidar com um campo em um banco de dados relacional que é essencialmente um valor enumerado, é uma decisão de design melhor tornar esse campo um número inteiro ou uma string? Ou há alguma outra alternativa que eu tenha esquecido?

Nota: tipos enumerados explícitos não são suportados pelo banco de dados que estamos usando. E o software que estamos desenvolvendo que fará interface com esse banco de dados está escrito em C ++.

Os tipos enumerados devem ser uma tabela separada em seu banco de dados que tenha um número de identificação e um nome de sequência e quaisquer outras colunas que você possa achar úteis. Cada tipo existe como uma linha nesta tabela. Em seguida, na sua tabela você está registrando as transações, o campo "trans_Type" deve ser uma chave estrangeira para a chave dessa tabela de referência. Essa é uma prática padrão na normalização de banco de dados.

Dessa forma, você armazenou a sequência de um nome oficial, utiliza comparações de números para desempenho e possui integridade referencial de que toda transação possui um tipo válido.

Uma prática comum é criar uma trans_typestabela e fazer com que sua tabela principal faça referência a ela com chave estrangeira nomeada trans_type_id. Isso garante que seus registros façam referência apenas a tipos enumerados válidos.

Exemplo:

trans_type
----------
  Eu iria
  nome

transações
------------
  Eu iria
  trans_date
  detalhes
  trans_type_id (FK para trans_type.id)

Dados de exemplo:

trans_type

ID NOME
----------
1 | ENVIAR
2 CANCELAR


transações

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

Se os valores estiverem entrando no banco de dados como números inteiros, armazene-os dessa maneira. Não há necessidade de sobrecarregar a conversão em strings enquanto escreve no banco de dados. Você sempre pode se relacionar a uma tabela de pesquisa com os valores de sequência / texto (Mais Normalizado).

Isso tem a vantagem adicional de atualizar o valor da sequência em um único local, em vez de executar algum tipo de rotina de atualização. Em vez de 1 = 'Vermelho', poderia ser igual a 'Realmente Vermelho'

Isso não é ideal para relatar desempenho em comparação com apenas precisar de uma tabela com valores de sequência (desnormalizada). Um índice nesse campo tornaria o desempenho bom o suficiente.

A maioria dos RDBMS permitirá potência suficiente. Embora sua idéia de poder 'ler' a tabela em sua forma simples de dados, ingressar em uma tabela não é grande coisa. Apenas adquira o hábito de usar uma visualização ou outro objeto similar.

Eu tenho que discordar das outras respostas a esta pergunta, defendendo a abordagem separada da tabela de enumeração.

No entanto, certamente sou a favor de não repetir o que já foi dito, por isso vou simplesmente me referir à resposta aceita (mais ou menos) à mesma pergunta no Stack Overflow: /programming//a/229919 / 114626