Reputation: 128807
How should I store an Java Enum in JavaDB?
Should I try to map the enums to SMALLINT
and keep the values in source code only? The embedded database is only used by a single application. Or should I just store the values as DECIMAL
? None of these solutions feels good/robust for me. Is there any better alternatives?
Here is my enum:
import java.math.BigDecimal;
public enum Vat {
NORMAL(new BigDecimal("0.25")),
FOOD(new BigDecimal("0.12")),
BOOKS(new BigDecimal("0.06")),
NONE(new BigDecimal("0.00"));
private final BigDecimal value;
Vat(BigDecimal val) {
value = val;
}
public BigDecimal getValue() {
return value;
}
}
I have read other similar questions on this topic, but the problem or solution doesn't match my problem. Enum storage in Database field, Best method to store Enum in Database, Best way to store enum values in database - String or Int
Upvotes: 7
Views: 6931
Reputation: 625057
In JPA, you have two choices:
By name;
By ordinal (integer).
I don't like (2). If you change the order of your enum it breaks. As such it's more common to use (1) (in my experience).
I would do the same in JavaDB. Just store the enum name as text. It has the advantage that you can look at a row and know what it means rather than trying to figure out what "3" means in the status_id column.
If you're concerned about space (and 99% of the time I wouldn't be) either use an integer or use a code. For example:
public enum Vat {
NORMAL(new BigDecimal("0.25")),
FOOD(new BigDecimal("0.12")),
BOOKS(new BigDecimal("0.06")),
NONE(new BigDecimal("0.00"));
private static final Map<String, Vat> LOOKUP = new HashMap<String, Vat>();
static {
Vat[] values = values();
for (Vat vat : values) {
LOOKUP.put(vat.code, vat);
}
}
private final String code;
private final String value;
private Vat(String code, BigDecimal value) {
this.code = code;
this.value = value;
}
public String getCode() { return code; }
public String getValue() { return value; }
public Vat fromCode(String code) {
return LOOKUP.get(code);
}
}
Upvotes: 9
Reputation: 54695
My preference is to do as follows:
Advantages
YourEnum
table.This is similar to cletus's solution except that the enum encoding is stored explicitly in the database rather than being defined as part of the enum definition.
Upvotes: 4