Enum in application Vs database table

[sid7]

Hello,

I'd like to get people's opinion on the below.

Let's say we want to create a constant mapping between int & String within our application.

An obvious solution is to create an Enum with a getter() which returns the String based on a given int.

However, we could also create a database table which defines this mapping.

I'm not quite sure which solution has the upper hand (if any) over the other. Would like to get some thoughts.

Thanks,
Sid

[~s.o.s~]

They are different yet there is no v/s IMO, there are a few tricks to persisting enums to databases out there, namely writing out the enum name and reading it back by passing the same name to valueOf() method for that enum.

The most obvious difference is that enums are compile time constants whereas key-value pairs stored in databases are configurable. Are you absolutely sure that these mappings won't change over time? If yes, you can have an enum having fixed set of values and when it comes to persisting just persist the enum name which can be easily used to get back the original enum. If you don't have a fixed set of values, the compile time advantage offered by enums is a moot point here since you can't create compile time safe mappings on the fly.

In the end it all depends on *what* exactly you are trying to achieve. But yes, there are ways of mixing and matching enums and database mappings as long as you know what you are dealing with.

[sid7]

Thanks for your reply.

You mentioned "key-value pairs stored in databases are configurable", surely an Enum can be modified in the same way as the database entry, no ? It's just the question that from an SDLC perspective, is it encouraged to maintain this mapping in the application itself, or database? Baring in mind that the mapping has absolutely no impact on database relationships.

Sid

[~s.o.s~]

an Enum can be modified in the same way as the database entry, no

They can be modified, but not in the same was as you can do it for database entries. Updated database entries would be visible to the application code almost immediately (or would require flushing the cache if you are caching) but for enum related changes you'd require either a restart (in case we are talking about deployed/managed applications) or an update to client (in case of standalone applications), both of which are pretty involved tasks.

Also, depending on *what* you are representing as key-value pair, it might result in the "enum" solution totally going out of hand with a large number of entries. Also, the database solution would be a good choice if the "would be" enum you talk about would have to be in the end persisted in a database. If for your particular use case, the "enum" is part of only the application logic and not your persistence logic along with having a fixed set of values, the enum solution is a pretty good one.

As already mentioned in my previous post, there can be no black-white answer to this thing; it'd all depend on what you are dealing with though with the points I've raised, you might be better equipped with making a decision.

EDIT: Also, a common anti-patten with enums is to think of them as configurable type-safe entities. If you need something configurable, you are better off using wrapper classes with normal fields rather than enums. A classic example would be: the rate of interest offered by different banks. Sure, you can store them all in an enum, but would that be a good choice. IMO, no.

Another use case would be the algorithm name and tweak parameter used by your banking application. Would enum be a good fit here? Maybe. Would enum would still be a good fit if the management requires you to tweak the parameters on fly? Probably not. I hope you see the pattern here.

[sid7]

Thanks, I do see your point.