Comments on: Modeling enumerated types in the database http://gabrito.com/post/modeling-enumerated-types-in-the-database Anecdotes on Java, Ruby, Sysadmin, SEO, Design, and Management Tue, 06 Jan 2009 23:58:51 +0000 http://wordpress.org/?v=2.7 hourly 1 By: Steve http://gabrito.com/post/modeling-enumerated-types-in-the-database/comment-page-1#comment-39839 Steve Mon, 18 Jun 2007 04:36:50 +0000 http://gabrito.com/post/modeling-enumerated-types-in-the-database#comment-39839 Do you know of a good pattern for mapping java 5 enums to a lookup table in hibernate so : - You get the ease of using a Java enum in your code - You get the lookup table ensuing FK constraints on the DB as well as lookup tables being a common pattern in legacy databases. I've been thinking about it ... but haven't come up with anything better than mapping the class normally and then writing a regular java enum where I create a map of lookup table ids to the enum values (and a getter for the id from the enum) ... it works, but it just seems wrong ... Do you know of a good pattern for mapping java 5 enums to a lookup table in hibernate so :
- You get the ease of using a Java enum in your code
- You get the lookup table ensuing FK constraints on the DB as well as lookup tables being a common pattern in legacy databases.

I’ve been thinking about it … but haven’t come up with anything better than mapping the class normally and then writing a regular java enum where I create a map of lookup table ids to the enum values (and a getter for the id from the enum) … it works, but it just seems wrong …

]]> By: Uri Boness http://gabrito.com/post/modeling-enumerated-types-in-the-database/comment-page-1#comment-1115 Uri Boness Wed, 31 May 2006 01:15:33 +0000 http://gabrito.com/post/modeling-enumerated-types-in-the-database#comment-1115 I don't think it's wise to make it a rule of thumb. In some cases, indeed the database is the proper place for the values for exactly the reasons you mentioned - this is usually the case where the enum type serves some purpose in the domain model. There are other enum types though that serve other purposes... an example for that is user role. In applications where the user roles are static, you can treat it as an enum type, but puting this in the database introduces another downside, which should not be taken lightly... the code *must* be in-sync. with the database at all time. In such situations, I prefer using approach no. 2. Of course, if your requirements can handle it, you can always save string keys instead of integers, so you still keep some documentation in the database (e.g. in case of java 5 enum, you can use the enum name(). I don’t think it’s wise to make it a rule of thumb. In some cases, indeed the database is the proper place for the values for exactly the reasons you mentioned - this is usually the case where the enum type serves some purpose in the domain model. There are other enum types though that serve other purposes… an example for that is user role. In applications where the user roles are static, you can treat it as an enum type, but puting this in the database introduces another downside, which should not be taken lightly… the code *must* be in-sync. with the database at all time. In such situations, I prefer using approach no. 2. Of course, if your requirements can handle it, you can always save string keys instead of integers, so you still keep some documentation in the database (e.g. in case of java 5 enum, you can use the enum name().

]]> By: F. Degenaar http://gabrito.com/post/modeling-enumerated-types-in-the-database/comment-page-1#comment-1098 F. Degenaar Tue, 30 May 2006 12:39:05 +0000 http://gabrito.com/post/modeling-enumerated-types-in-the-database#comment-1098 There's a 4th kind of solution to this problem located somewhere between option 2 and option 3: Use option 2 in combination with Java 5 or Jakarta Commeons Enums, but provide only a message key in the toString() method like "com.foobar.EmployeeState.2". The actual output string can be dealt with in a ResourceBundle. The icing on the cake is to build this ResourceBundle from a database table including the locale data. This way, one can lookup the text mapped to a particular state inside the database, I18N issues are elegantly resolved, and the output texts can be cached inside the application. Just my 0.02 EUR Fokko There’s a 4th kind of solution to this problem located somewhere between option 2 and option 3:
Use option 2 in combination with Java 5 or Jakarta Commeons Enums, but provide only a message key in the toString() method like “com.foobar.EmployeeState.2″. The actual output string can be dealt with in a ResourceBundle.
The icing on the cake is to build this ResourceBundle from a database table including the locale data. This way, one can lookup the text mapped to a particular state inside the database, I18N issues are elegantly resolved, and the output texts can be cached inside the application.

Just my 0.02 EUR
Fokko

]]>