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.