Question

I am not able to make a clear decision on this one.

I am OK by having numeric values on my tables and have the value information on the description of the column on the database for DBA.

But I also don’t want to come to a point in future where having these numeric values on database creating too much headache for maintenance.

I’m not feeling particularly drawn to having strings for these enum columns on database either as it will create a lot of duplicated string repetition on the database. It might not be a major performance issue but does not feel that right to me to have so much string on a table to indicate a value.

Can you please share your thoughts from your long term experience. Thank you

Answer 1

The standard way to deal with your situation is via lookup tables. Generally, these have a simple structure (often just two columns):

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

You might or might not make the name column unique too. Then for a table that contains values of the relevant type, you use:

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

Here, I’ve not been very clever with the names; you might use ‘CustomerStatus’ in place of ‘LookupTable’ and then use the column name CustStatus in ReferencingTable. You can choose a variety of types for the ‘code’ column – a single byte tiny integer, a small CHAR field, or an INTEGER, depending on how many values you might need. Sometimes the lookup table becomes more complex and acquires extra attributes describing the entity, too, though that typically means that it is modelling an entity of some importance to your DB and it is no longer ‘just a lookup table’.

You can end up with quite a lot of these lookup tables, but resist the temptation to fall into the trap of generalizing to the ‘One True Lookup Table’ (OTLT) idiom. As documented in other SO questions and elsewhere on the web, this leads to data integrity problems.