user1884155
user1884155

Reputation: 3736

Using an enum in Java as an alternative to a small database

I have a java application which uses a class "Country". The business logic associates each country in the world with:

  1. An iso code.
  2. A telephone country calling code
  3. A list of TZ database timezone ids suitable for that country

Normally, this is data is perfect for a database. However, given the fact that this data is quite stable (sure, it changes now and then, but it is normally not used to perform create/update/delete operations on those records) I was thinking about maybe putting the information in an enumeration like this:

public enum Country
{

   US(1,new String[]{"America\New York","America\California",...}),

   ...

   NL(31, new String[]{"Europe\Amsterdam"});

    ...

    public Country(int telephoneCode, String[] timezoneIds)
    {
       ...
    }
}

Possible advantages to this approach:

  1. Data is directly accesible from java source code, so there is no delay with doing database queries.
  2. No need to set-up and maintain a database file somewhere (which is a big deal for me, because I'm not familiar with JDBC yet)

The disadvantages could be:

  1. Data is "hidden" inside the source code and is not updated automatically if politics change.
  2. Code must be redistributed if enums change. (See this question.)
  3. How well is the performance of "big" enums (more than 200 possible values) compared to database queries to get specific information?

I would like to ask about the bolded question (disadvantage #3), but any comments regarding the bigger picture are welcome.

I am aware of the Locale class in java which can be used to get a list of all possible countries known in the java system. Unfortunately, telephone and timezone information is not available. My intent is too merge this data into one enumeration. Is this practice considered to be a plausible alternative or hackity anti pattern?

Upvotes: 4

Views: 829

Answers (2)

kapex
kapex

Reputation: 29959

I can only agree with the comments so far. A list of countries may change but it will always be small enough to keep the whole list in memory. Any difference in performance doesn't really matter if it is only queried once and then cached.

It probably depends on who is using the software (personal use or a large company) but I would say the biggest concern here is #2, not #3. In code vs. in database should be decided based on who might has to change the values later. Are you really ok that you need a developer to change a value, recompile everything and roll out a new version or patch of the software? Just updating a text file or the database will be much easier.

If it's a personal project that argument probably doesn't matter for you, but even then a text file (e.g. in CSV format) might be the easier to maintain than code. I would still recommend to use a simple database - just for the learning experience. You don't need to setup a huge database system like MySQL. You could use a small embeddable database like h2 or Apache Derby.


Just for reference how often country codes and names can change:

ISO 3611-1 (which defines the language and country codes for existing countries) has been changed 17 times in the years 2007-2014. That's about 2.4 times per year.

Upvotes: 5

venergiac
venergiac

Reputation: 7717

No problem to create an Enum: generally speaking it is infrequent a change of Countries.

My suggestions:

  1. Using Enum
  2. store data on Db and load items during initialization (static cache)
  3. use a hit and miss cache (JCS, EHCache, ... )
  4. use a Resource Bundle

Upvotes: 1

Related Questions