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

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.