Question

I’m implementing a database table like the following:

Do_Something
------------
Id
Name
Frequency

Frequency can only be 1 of 3 values at the moment; immediate, daily or weekly. So I can implement the Frequency field as a String, in which case the hibernate mapping would be a simple easy enum. However, as easy as the code implementation is, it seems ugly and inefficient on the database side with hundreds of thousands of Strings. So maybe I had a frequency table:

Frequency
---------
Id
Value

And now I have the Do_Something.Frequency field as a foreign key to this table. Now I have to hardcode the preset frequencyIds in my code to make querying the Do_Something table easier to deal with. I’m not sure how much use the Frequency table will have aside from within the Do_Something table. Maybe in the future other tables will make use of it…

So the question is, do I make frequency a simple enum in code and in the db as a String, or make frequency an enum in code that gets translated to and from a frequency_id in the db or make frequency constants in code that match the various possible frequency ids in the db?

Answer 1

So it boils down to whether you want to keep Frequency normalized or not. There is a lot written about it but my take is that unless you expect regular changes in values of Frequency, there is not much need for complexity of extra table.

I would consider enum with some additional display name and well established string names. That would give you a chance to rename presentation name if needed without changing database.
For example:

IMMEDIATE("Immediate"),
DAILY("Daily"),
WEEKLY("Weekly")

Drawback is that if you ever decide to change those enum values you will have to migrate database. But from practical standpoint, why would you ever want to rename them?