wood burning stoves 2.0*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Meta: Should ENUMs that are displayed to the User be standard Java Enums, or stored in a DB table Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Meta: Should ENUMs that are displayed to the User be standard Java Enums, or stored in a DB table" Watch "Meta: Should ENUMs that are displayed to the User be standard Java Enums, or stored in a DB table" New topic
Author

Meta: Should ENUMs that are displayed to the User be standard Java Enums, or stored in a DB table

Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4646
    
    5

Sorry, this is meaningful, but I could not find a good matching section. If there is an obvious better place, feel free to move it.

I'm soliciting opinions and experiences on the "best" binding between constants and the user experience.

Assume you have a standard Java Enum of PoliticalParties, containing {Republican, Democrat, Tories, Labor}
The way to use this is obvious, and you can store values into your DB either as strings or ordinals. Now, lets say that the LibDems want to be included in your application, so you change the class, add it, and all is good. But you also have to change your servlets, JSP pages, AJAX javascript, etc. to match. As long as it happens "slowly" its OK. But what if you find that you have to add "TeaParty" to the list, and "Congress" and there is no end in sight. This seems like a lot of work for very little benefit, and is a potential bugfarm.

One possible approach is to replace the enum class with a DB table, say politicalparties, which you can read in at application startup. This lets the number and spelling of the values be controlled outside the code.

Ignoring the minor issues such as losing SVN/CVS/GIT control over the values and who changed them, this DB-based approach lets the programmer do it once and get lots of code reuse.

What do the experienced folks think of each approach?

if the DB approach is "good" in some cases, what are the characteristics of the cases?

It seems to me that having a DB table to contain "true" and "false" for a boolean is carrying this way too far, but is it worthwhile for 5 values? or 10 values? or ??

Thanks
Pat



Ryan McGuire
Ranch Hand

Joined: Feb 18, 2005
Posts: 1006
    
    3
Pat Farrell wrote:
It seems to me that having a DB table to contain "true" and "false" for a boolean is carrying this way too far, but is it worthwhile for 5 values? or 10 values? or ??



IN MY EXPERIENCE...
It's not a question of how many values there are in the ENUM but rather how often they're going to change. Nobody is ever going to change the spelling of Zero, One, Two, etc.* True and False might change to Yes and No once over the next two years. You will definitely have to add new political parties at least four times a year (for the sake of discussion).

* unless you go multi-lingual.

HOWEVER...
Regardless of whether you use a Java enum or a DB table (or a flat file, or XML, or web service, or...) for the love of all that you hold dear, adhere to the "Don't Repeat Yourself" (aka DRY) principle. i.e. Make sure there is only one "authoritative" version of the list that is then propagated out to any component that needs it.

I promise, if you have the "same" list in, say, a DB and hardcoded into an HTML page, the two lists will get out of sync. The list doesn't necessarily have to propagated at run time, e.g. you don't have to read the DB to generate the HTML page on-the-fly every time it's requested. However you really should have a a programmatic way to read the database and generate the HTML when needed. Maybe it's once an hour, maybe every day at midnight, maybe there's a SQL trigger when the DB table gets updated that fires off the sync program.

This is obviously true for the components of a single system (e.g. the M, V, and C of the HR system). It also holds for lists that are used by multiple systems, EVEN IF there are no current plans to integrate the systems. HR, Accounting, Billing, Operations, etc. will ALL need an accurate idea of, for example, which Departments are in which Divisions. Rather than each system having a private list, they should all get their info from one central place.

Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4646
    
    5

They are going to change, as my example shows. There was no "Tea Party" just a year or two ago.

I picked the example as a placeholder for things that change never, your "one, two, three" and things that change daily, say the most popular song on the radio.

With ubiquitous Javascript binding to servlets to code, AJAX, etc. no matter what you change, its painful.
D. Ogranos
Ranch Hand

Joined: Feb 02, 2009
Posts: 214
Pat Farrell wrote:...Now, lets say that the LibDems want to be included in your application, so you change the class, add it, and all is good. But you also have to change your servlets, JSP pages, AJAX javascript, etc. to match...


I don't know your application, but if you have to change jsps and javascript stuff whenever you add a constant, then you probably would have to change them also if you pull the constants somewhere else then from an enum, wouldn't you?

IMO, enums are for *constant* values, if the values change often then perhaps an enum shouldn't be used at all.
Ryan McGuire
Ranch Hand

Joined: Feb 18, 2005
Posts: 1006
    
    3
D. Ogranos wrote:
IMO, enums are for *constant* values, if the values change often then perhaps an enum shouldn't be used at all.


That's exactly the point... just how often is "often"?
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4646
    
    5

There are very few constants in the world.

The question is now how constant a given constant is, but how to deal "best" with constants that change somewhat slowly for suitable values of slowly.

Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60780
    
  65

Overly-simplified rule-of-thumb that works 99% of the time: if the list is constant enough that any change will be part of the next released version "New! Improved! Now with support for Cholula Hot Sauce", I'll place it in an enum.

If it's something that we want to be able to change mid-stream without code changes, it goes in the database.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Bear Bibeault wrote:Overly-simplified rule-of-thumb that works 99% of the time: if the list is constant enough that any change will be part of the next released version "New! Improved! Now with support for Cholula Hot Sauce", I'll place it in an enum.

If it's something that we want to be able to change mid-stream without code changes, it goes in the database.


Yea, for me the key point is does adding a new value require code to change, aside from the enum itself. If no, DB all the way baby! If yes, Enum.


GenRocket - Experts at Building Test Data
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4646
    
    5

Gregg Bolinger wrote:does adding a new value require code to change, aside from the enum itself. If no, DB all the way baby! If yes, Enum.


I can't follow your logic here. Ignoring the change to the enum.Java file itself, what are you saying? It looks like

if (changes ripple through lots of stuff)
use Enum
else
use DB to hold values

This is, at least, 180 degrees out of sync from my understanding. Am I misreading you response?
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

If you need to add a value to an Enum you need to reploy you code. This is ok so long as you need to make some other changes (in line with what Bear said). But if adding the value requires nothing more than the value, a DB would be better because then you don't need to redeploy your application. Exceptions to this rule exists I'm sure. But this is the standard by which I try and decide which to go with.
Ryan McGuire
Ranch Hand

Joined: Feb 18, 2005
Posts: 1006
    
    3
Bear Bibeault wrote:Overly-simplified rule-of-thumb that works 99% of the time: if the list is constant enough that any change will be part of the next released version "New! Improved! Now with support for Cholula Hot Sauce", I'll place it in an enum.

If it's something that we want to be able to change mid-stream without code changes, it goes in the database.


Just to add my own clarification...
A list of "constants" can/should be an enum if the list is constant enough that any required changes can wait for the next released version without being the sole cause for the next release.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Meta: Should ENUMs that are displayed to the User be standard Java Enums, or stored in a DB table
 
Similar Threads
Issue with assigning enum instance variable
Storing Enum Types
Enum representing DB table.
Enumerations: How should they be implemented?
PropertyKeys