Keep enumeration in DB when data associated with it is not storable in DB

Question

I've seen several questions on this website explaining that enums should be kept in the database when there is one (this one for example). However, I feel like my case is different and there are extra elements to take in consideration.

The application I'm working on provides a user interface for people to customize "screens" (which are basically webpages) based on a somewhat limited set of "modules". We want to give a frame to the end users, so for every module there will be limited customization. The module will be created by hand, and then the module plus the values entered by the user will be parsed to create the webpages. Our environment is very specific, so it won't necessarily be HTML directly, but we can consider it to be HTML.

I feel like we can't store the entire modules in the database, especially the functions used to parse the user input to generate the output. However, other rows in DB will need to reference that module. In that case, what would be the best way to go ? Should I do a simple "enum" table and use foreign keys in the DB, and in the app connect values of the enum with the associated procedures, or should I just write a string "ID" of the class in the columns supposed to reference those modules, minimizing the DB complexity and keeping the modules more "centralized" in the app ?

There is no sharing of the DB tables and there is no planned sharing of the DB tables either.

Answer 1

The question you link to is saying to put enums in the database when the data that uses those enums is stored in the database. This is to take advantage of constraints and foreign key relationships when you query the database.

If the data using enum values isn't in the database, there is no advantage at all in adding another query to the database when you're not going to get constraint or foreign key behaviour.

So, in your case, keep the enum and constraint logic together with your data model.