JPA Enum ORDINAL vs STRING

Question

It\'s possible to define enumerations in JPA using either

@Enumerated(EnumType.ORDINAL)

or

@Enumerated(EnumType.STRING)
         


        

Answer 1

Are you really sure that a human readable database is what you need? Storing string value is a waste of space. The only compromise with readability could be use @Enumerated(STRING) and map database column as ENUM (if you are using mysql... I presume other dbms have something similar) but it's a real pain when you have to change enum names.

Answer 2

This is a good question. In the past I used String but today my preference is usually Ordinal.

The main disadvantage for the String is for the DBAs. With the String they have no idea what is the possible values of the column, because this information is in the application code. The DBA only can have some idea about the possible values grouping the existent information on the table, but he will never be sure about the other possible values or if new values are added, until the application insert them on the table.

In the Ordinal you have the same problem. But my preference for Ordinal came to a solution to the DBA problem that seems natural to the database. You create a new table to show the possible values of the Enumerator on database, with a foreign key between the column (ordinal enum value) and this new table. This strategy is described and implemented here.

About the problem that someone could reorder the Enumerator and break the system, a simple unit test can deal with this problem and guarantee that no one will reorder them without a good warning. The same idea is valid on renaming the Enumerator. So, renaming (on String) or reorder (on Ordinal) accidentally is not really a strong argument against String or Ordinal approach.

By the way, the developers have more necessity to rename than reorder an Enumerator, so this is one more positive point in use Ordinal.

So, with this approach, you resolve the main problem of the Ordinal (now, is readable), the information will occupy less space on the database and your DBA will be happy.

Answer 3

I would prefer EnumType.STRING. A disadvantage of EnumType.ORDINAL is the effect of time and the desire to keep enums in a logical order. With EnumType.ORDINAL any new enum elements must be added to the end of the list or you will accidentally change the meaning of all your records. please check this link: https://tomee.apache.org/examples-trunk/jpa-enumerated/

Answer 4

It's likely that ORDINAL is more efficient, but that's minor. There are a few downsides to ORDINAL:

• it is less readable in the database
• if you reorder your enum definitions the database will not be consistent.

With STRING you can't rename your enums.

Pick one of them and use it throughout the whole application - be consistent.

If your database is going to be used by other clients/languages - use STRING, it's more readable.

Answer 5

I always go STRING.

Speed is rarely the most important issue - readability and maintainability are more important.

I use STRING because it's a lot easier to manually inspect rows from the database, but more importantly, I can do two things, without touching the database, the ORDINAL can't handle:

1. I can change the order of my enums
2. I can insert new enums in the middle of the enum list

Both of these changes will alter the ordinal values of the enums already in use in the database, thus breaking existing data if you are using ORDINAL.

If you change an enum value (not that common), handling it is simple:

UPDATE table SET enum_column = 'NEW_ENUM_NAME' where enum_column = 'OLD_ENUM_NAME';

Answer 6

Lots of good advice here, but I just wanted to add something I didn't see yet:

Regardless of the solution you choose, don't forget to add a big fat warning at the top of your enum class saying which should be used. Hopefully other developers will see you've done this and use the same method for saving the enum.