Énumérations persistantes sous forme d'octet ou de texte dans la base de données

Question

Je ne suis pas en mesure de prendre une décision claire à ce sujet.

Je suis OK en ayant des valeurs numériques sur mes tables et avoir les informations de valeur sur la description de la colonne sur la base de données pour DBA.

Mais je ne veux pas non plus venir à un point où ces valeurs numériques sur la base de données créeraient trop de maux de tête pour la maintenance.

Je ne me sens pas particulièrement attiré par l'existence de chaînes pour ces colonnes enum dans la base de données, car cela créerait beaucoup de répétitions de chaînes dupliquées dans la base de données. Ce n'est peut-être pas un problème de performance majeur, mais je ne me sens pas le droit d'avoir autant de ficelle sur une table pour indiquer une valeur. Pouvez-vous s'il vous plaît partager vos pensées à partir de votre expérience à long terme?

Merci

Answer 1

La façon standard de traiter votre situation est via des tables de recherche. En général, ceux-ci ont une structure simple (souvent seulement deux colonnes):

CREATE TABLE LookupTable 
(
    code SMALLINT NOT NULL PRIMARY KEY, 
    name VARCHAR(32) NOT NULL 
); 

Vous pourriez ou ne pas faire la colonne de nom unique aussi. Ensuite, pour une table qui contient des valeurs du type concerné, vous utilisez:

CREATE TABLE ReferencingTable 
(
    ... 
    lookup SMALLINT NOT NULL REFERENCES LookupTable, 
    ... 
); 

Ici, je n'ai pas été très intelligent avec les noms; vous pouvez utiliser 'CustomerStatus' à la place de 'LookupTable', puis utiliser le nom de colonne CustStatus dans ReferencingTable. Vous pouvez choisir une variété de types pour la colonne 'code' - un entier minuscule à un octet, un petit champ CHAR, ou un ENTIER, selon le nombre de valeurs dont vous pourriez avoir besoin. Parfois, la table de recherche devient plus complexe et acquiert des attributs supplémentaires décrivant l'entité, bien que cela signifie généralement qu'elle modélise une entité d'une certaine importance pour votre base de données et qu'elle n'est plus simplement une table de recherche.

Vous pouvez vous retrouver avec un grand nombre de ces tables de recherche, mais résister à la tentation de tomber dans le piège de la généralisation à l'idiome «One True Lookup Table» (OTLT). Tel que documenté dans d'autres questions SO et ailleurs sur le web, cela conduit à des problèmes d'intégrité des données.