I am working on a project where there will be plenty of static options being stored in the database. I looked at using Enums for this, but do not see how they could be useful.
They do not create any kind of look-up table, just reference a number in the table which can be used in code as an enum option. The number is meaningless to anyone creating SSRS reports and if you need to add an extra option, you need to recompile.
Is there a situation where these have a genuine purpose and are a better fit than an entity. Or are they generally a bad practice for the above reasons?
1
Using a number to represent an enum value is slightly more efficient in terms of database lookup. The downside is of course that it is ghastly difficult to understand what anything is.
This is a matter of opinion, however I believe emphasis should be placed on readability, also in the database. As such, I would prefer readable string values in the database. However, you lose the advantage of using enums in your code, hence I would suggest to convert from enums to strings and vice versa. Use the enum name as it is used in your code and if it is minimally descriptive, you should easily be able to understand what type you’re dealing with by looking at the database.
You could also take this a step further and insert the full formal name of the enum type in order to recreate it using reflection, but I would avoid this technique if possible.
Also be sure that these values are really truly static in nature. Adding one or two extra enum types is no big deal, but more than that and you’re likely dealing with a dynamic value and at that point it should have its own database table.
2
For reporting scenarios, the database will not be able to report any meaningful information about the enum. This makes Entity Framework enums much less useful unless you use the enum to supply the name or text value, and graft that onto a class that represents the lookup table (which is not an EF enum, I realize).
Database enums are for situations where something is necessarily hard coded. The enum creates a binding between the database data and something that is hard coded into the source code.
Don’t think of that as meaning that they are never useful, since there are situations where this is acceptable and necessary. Rather, don’t use an enum unless you have this kind of situation of needing to relate directly to something in code that wouldn’t make sense as data or simply cannot be extracted into data.
Some examples include:
-
A list of the program’s features. For example, I have menu structure in the database from which menus are built based on user authorization, but it needs to refer to actual functions in the source that get executed. An enum binds a database value to actual source code.
-
A type of control. If you have a dynamic interface that is defined in the database, in order to say “a combobox”, “a textbox”, etc., you need some kind of value to use to refer to these things. An enum binds database values to types of control. (You need not be referring directly to the control type, but could be defining some kind of control pattern, like a group of radio buttons or checkboxes.)