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?
Best Answer
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.