1

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.

7
  • that linked answer is completely wrong
    – Ewan
    Commented Jul 4, 2018 at 12:30
  • @Ewan: Assertions like that are useless unless you can explain why.
    – Robert Harvey
    Commented Jul 4, 2018 at 14:28
  • @RobertHarvey not true. in this case the OP has been mislead by assuming that the answer is correct. A simple assertion shows that that assumption may not be true
    – Ewan
    Commented Jul 4, 2018 at 15:56
  • @Ewan: Without some rationale the assertion is worthless. Quit proscribing and start explaining; it's assertions like this that make our profession such a terrible place to navigate.
    – Robert Harvey
    Commented Jul 4, 2018 at 16:00
  • @RobertHarvey not true, it demonstrates division of opinion. theres no point in going into the whys, the question is based on an incorrect assumption, but is not about that assumption
    – Ewan
    Commented Jul 4, 2018 at 16:02

1 Answer 1

Reset to default
2

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.

2
  • What should I do in the application then ? My concern is that if the enum is separated, I don't have tight coupling between the set of values represented by the enum and the treatments associated with the values. Basically, there's no guarantee that a procedure in the is associated to a certain enum value in DB, and there's no guarantee that every value can be processed by the program, at least until you try to process the values and realize something is wrong, which I feel could be prevented with other solutions (but I may well be wrong).
    – ZamenWolk
    Commented Jul 5, 2018 at 7:43
  • Put the enum where it makes sense - if you have data that refers to the enum in your database, put it in your database.
    – HorusKol
    Commented Jul 5, 2018 at 11:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.