Come devo rappresentare un tipo elencato in un database relazionale?

Sto lavorando allo sviluppo di un database relazionale che tiene traccia delle transazioni che si verificano su un dispositivo su cui sto lavorando per la mia azienda. Esistono diversi tipi di transazioni che potrebbero verificarsi sul dispositivo, quindi abbiamo un campo "trans_type" in una delle nostre principali tabelle dei record. Il mio gruppo ha deciso di trasformare il tipo di questo campo in un numero intero e di trattarlo come un tipo elencato. La mia intuizione mi dice che sarebbe una buona idea rendere questo campo una stringa in modo che i dati del nostro database siano più leggibili e utilizzabili. I miei colleghi sembrano preoccupati che ciò causerebbe più problemi di quanti ne valga la pena. I confronti delle stringhe sono troppo costosi e la possibilità di errori di battitura è una barriera troppo grande.

Quindi, secondo te, quando si ha a che fare con un campo in un database relazionale che è essenzialmente un valore elencato, è una migliore decisione progettuale rendere questo campo un numero intero o una stringa? O c'è qualche altra alternativa che ho trascurato?

Nota: i tipi enumerati espliciti non sono supportati dal database che stiamo utilizzando. E il software che stiamo sviluppando che si interfaccia con questo database è scritto in C ++.

I tipi enumerati dovrebbero essere una tabella separata nel database con un numero ID, un nome stringa e qualsiasi altra colonna che potresti trovare utile. Quindi ogni tipo esiste come una riga in questa tabella. Quindi nella tua tabella stai registrando le transazioni il campo "trans_Type" dovrebbe essere una chiave esterna alla chiave di quella tabella di riferimento. Questa è una pratica standard nella normalizzazione del database.

In questo modo hai memorizzato una stringa di nome ufficiale, puoi usare i confronti numerici per le prestazioni e avere l'integrità referenziale che ogni transazione ha un tipo valido.

Una pratica comune è quella di creare una trans_typestabella e quindi fare in modo che la tabella principale lo faccia riferimento con una chiave esterna denominata trans_type_id. Ciò garantisce che i record facciano riferimento solo a tipi enumerati validi.

Esempio:

trans_type
----------
  id
  nome

transazioni
------------
  id
  trans_date
  dettagli
  trans_type_id (da FK a trans_type.id)

Dati di esempio:

trans_type

ID | NOME
----------
1 | INVIA
2 | ANNULLA


transazioni

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

Se i valori arrivano nel database come numeri interi, archiviarli in questo modo. Non è necessario mettere il sovraccarico della conversione in stringhe durante la scrittura nel database. Puoi sempre fare riferimento a una tabella di ricerca con i valori stringa / testo (Più normalizzati).

Ciò ha l'ulteriore vantaggio di aggiornare il valore della stringa in una singola posizione anziché eseguire una sorta di routine di aggiornamento. Invece di 1 = "Rosso" potrebbe essere uguale a "Davvero rosso"

Questo non è l'ideale per il reporting delle prestazioni rispetto alla necessità di una sola tabella con valori stringa (denormalizzati). Un indice su questo campo renderebbe le prestazioni abbastanza buone.

La maggior parte dei RDBMS consentirà una potenza sufficiente. Sebbene la tua idea di essere in grado di "leggere" la tabella nel suo semplice modulo dati, unirti a una tabella non è un grosso problema. Prendi l'abitudine di usare una vista o un oggetto simile.

Non sono d'accordo con le altre risposte a questa domanda a favore dell'approccio della tabella di enumerazione separata.

Tuttavia, sono certamente favorevole a non ripetere ciò che è già stato detto, quindi farò semplicemente riferimento alla risposta accettata (più o meno) alla stessa domanda su Stack Overflow: /programming//a/229919 / 114626