Home/ Questions/Q 142389
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T07:55:43+00:00

Most projects have some sort of data that are essentially static between releases and

  • 0

Most projects have some sort of data that are essentially static between releases and well-suited for use as an enum, like statuses, transaction types, error codes, etc. For example’s sake, I’ll just use a common status enum:

public enum Status {     ACTIVE(10, 'Active');     EXPIRED(11, 'Expired');     /* other statuses... */      /* constructors, getters, etc. */ }

I’d like to know what others do in terms of persistence regarding data like these. I see a few options, each of which have some obvious advantages and disadvantages:

  • Persist the possible statuses in a status table and keep all of the possible status domain objects cached for use throughout the application
  • Only use an enum and don’t persist the list of available statuses, creating a data consistency holy war between me and my DBA
  • Persist the statuses and maintain an enum in the code, but don’t tie them together, creating duplicated data

My preference is the second option, although my DBA claims that our end users might want to access the raw data to generate reports, and not persisting the statuses would lead to an incomplete data model (counter-argument: this could be solved with documentation).

Is there a convention that most people use here? What are peoples’ experiences with each and are there other alternatives?

Edit:

After thinking about it for a while, my real persistence struggle comes with handling the id values that are tied to the statuses in the database. These values would be inserted as default data when installing the application. At this point they’d have ids that are usable as foreign keys in other tables. I feel like my code needs to know about these ids so that I can easily retrieve the status objects and assign them to other objects. What do I do about this? I could add another field, like ‘code’, to look stuff up by, or just look up statuses by name, which is icky.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. We store enum values using some explicit string or character value in the database. Then to go from database value back to enum we write a static method on the enum class to iterate and find the right one.

    If you expect a lot of enum values, you could create a static mapping HashMap<String,MyEnum> to translate quickly.

    Don’t store the actual enum name (i.e. ‘ACTIVE’ in your example) because that’s easily refactored by developers.

    • 0