4

Is there a "canonical" way to represent a dictionary in - maintained through java persistence - database?

Lets say I have a table of people and there is a column "profession".

Set of professions is restricted but can be extended. Some professions have some special meanings for a system, like a military, or a doctor.

  1. I can use enum for professions and store string (name() method) values in database as it shown here. It is simple and readable.
  2. In database I can have a dictionary table 'profession' with professions (id, name_of_profession), and table 'people' which has foreign key (id_profession) from table 'profession'. Than enum will have an Integer id value that is mapped to id column in 'profession' table.

First solution is short and easy. But in that case, database without application has no integrity. Is the second "legacy" way inappropriate?

Community
  • 1
  • 1
Zbyszek
  • 647
  • 2
  • 8
  • 21

2 Answers2

2

I think you have identified the pros and cons of the two approaches. It is really up to you to decide which is better ... for your specific application.

Or to put it another way, "best practice" depends on your application's real requirements.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
0

You could use a combination of both schemes:

  • Have a Professions table with a single primary key, the name of the profession.

  • Have a People table with a foreign key constraint in the profession column.

Using a string for a primary/foreign key would affect update performance, but it makes each row in People self-contained, which benefits retrieval operations. Therefore, this alternative might be possible, unless a benchmark says otherwise.

Community
  • 1
  • 1
thkala
  • 84,049
  • 23
  • 157
  • 201
  • That's possible too. I was just curious, if there is a "best" or "appropriate" way. Now it seems to me, that it is a matter of current requirements and preferences. So there are at least, three possibilities. – Zbyszek Apr 14 '12 at 13:29