3

My application is a very typical business application that has a lot of reference lists. For example, i might have a table that has statuses (On Hold, In Progress, Complete, etc), or a table with countries, or a table with lists of options.

Currently I'm storing this reference data in tables, with one table per type (e.g., a Status table, Country table, etc). However it's now getting cluttered and the overhead for dealing with it is too high. (Adding a new reference table means updating all of the associated infrastructure).

Currently my solution has 4 parts:

  • A table to store the data
  • a business object for holding the record itself in memory (this is overkill)
  • A service class for reading and querying the data
  • When needed, an Enum so i can refer to certain reference data items in memory (e.g., if i want to refer to an "On Hold" status without hard-coding "4" everywhere.

I've looked around and found one relevant question here, but it's much more focused on caching. I'm looking for best practices focused on overall handling of reference data.

My current approach seems clumsy and i want to rework it so it's easier to work with. But before I dive in and create something that's only marginally better, can you please recommend or point me to best practices for managing and working with reference data?

Community
  • 1
  • 1
Brian B
  • 33
  • 3

1 Answers1

0

Your problem as I understand is proliferation of components because of a single table per reference data category design.

An alternative is to have a single table with the following schema:

Type Value "Country" USA "Country" Canada "Status" "READY" "Status" "OnHold"

Then you can have an intelligent class that knows how to store this schema into data structures such as:

Set<String> countries;
Set<Status> status;
..
..

You can have a single API or separate API with specific methods such as:

getCountryList();
addCountry();

The API will encapsulate the details of intelligently returning the appropriate data structures in whichever form and of adding new ones as well.

If you have a handful of these items and would like to not make multiple copies of these (and just reuse the existing single copies in memory) you can also use the FlyWeight pattern. The API described above will be a FlyWeight (http://en.wikipedia.org/wiki/Flyweight_pattern). This will address some efficiency concerns.

Just a crack at it.

Sid
  • 7,511
  • 2
  • 28
  • 41