Если у Вас нет причин реального исполнения избежать его, я рекомендовал бы использовать отдельную таблицу для перечисления. Используйте целостность внешнего ключа, если дополнительный поиск действительно не уничтожает Вас.

таблица Suits:

suit_id suit_name
1       Clubs
2       Hearts
3       Spades
4       Diamonds

таблица

player_name suit_id
Ian Boyd           4
Shelby Lake        2

1. Players, Если Вы когда-либо осуществляете рефакторинг свое перечисление, чтобы быть классами с поведением (такими как приоритет), Ваша база данных уже, моделирует его правильно
2. , Ваш DBA счастлив, потому что Ваша схема нормализована (хранение единственного целого числа на плеер, вместо всей строки, которая может или не может иметь опечаток).
3. Ваши значения базы данных (suit_id) независимы от Вашей перечислимой величины, которая помогает Вам работать над данными из других языков также.

Я утверждал бы, что единственный безопасный механизм здесь должен использовать Строку name() значение. При записи в DB Вы могли использовать sproc, чтобы вставить значение и при чтении, использовать Представление. Этим способом, если перечисления изменяются, существует уровень абстракции в sproc/view, чтобы быть в состоянии представить данные как перечисление значений, не "налагая" это на DB.

Как Вы говорите, порядковый немного опасно. Рассмотрите, например:

public enum Boolean {
    TRUE, FALSE
}

public class BooleanTest {
    @Test
    public void testEnum() {
        assertEquals(0, Boolean.TRUE.ordinal());
        assertEquals(1, Boolean.FALSE.ordinal());
    }
}

при хранении этого как ординалов у Вас могли бы быть строки как:

> SELECT STATEMENT, TRUTH FROM CALL_MY_BLUFF

"Alice is a boy"      1
"Graham is a boy"     0

, Но что происходит, если Вы обновили булевскую переменную?

public enum Boolean {
    TRUE, FILE_NOT_FOUND, FALSE
}

Это означает, что вся Ваша ложь станет неправильно истолкованной как 'file-not-found'

Лучше, чтобы просто использовать строковое представление

Мы просто храним само перечислимое имя - это более читаемо.

Мы действительно бездельничали с хранением определенных значений для перечислений, где существует ограниченный набор значений, например, это перечисление, которое имеет ограниченный набор состояний, которые мы используем символ для представления (более значимый, чем числовое значение):

public enum EmailStatus {
    EMAIL_NEW('N'), EMAIL_SENT('S'), EMAIL_FAILED('F'), EMAIL_SKIPPED('K'), UNDEFINED('-');

    private char dbChar = '-';

    EmailStatus(char statusChar) {
        this.dbChar = statusChar;
    }

    public char statusChar() {
        return dbChar;
    }

    public static EmailStatus getFromStatusChar(char statusChar) {
        switch (statusChar) {
        case 'N':
            return EMAIL_NEW;
        case 'S':
            return EMAIL_SENT;
        case 'F':
            return EMAIL_FAILED;
        case 'K':
            return EMAIL_SKIPPED;
        default:
            return UNDEFINED;
        }
    }
}

и когда у Вас есть много значений, у Вас должна быть Карта в Вашем перечислении для хранения этого getFromXYZ методом маленький.

Для большой базы данных я отказываюсь потерять размер и преимущества скорости числового представления. Я часто заканчиваю с таблицей базы данных, представляющей Перечисление.

можно осуществить непротиворечивость базы данных путем объявления внешнего ключа - хотя в некоторых случаях могло бы быть лучше не объявить, что как ограничение внешнего ключа, которое налагает стоимость на каждую транзакцию. Можно гарантировать непротиворечивость путем периодического выполнения проверки, во времена выбора, с:

SELECT reftable.* FROM reftable
  LEFT JOIN enumtable ON reftable.enum_ref_id = enumtable.enum_id
WHERE enumtable.enum_id IS NULL;

другая половина этого решения должна записать некоторый тестовый код, который проверяет, что перечисление Java и таблица перечисления базы данных имеют то же содержание. Это оставляют как осуществление для читателя.

При сохранении перечислений как строк в базе данных можно создать служебные методы для (de), сериализируют любое перечисление:

   public static String getSerializedForm(Enum<?> enumVal) {
        String name = enumVal.name();
        // possibly quote value?
        return name;
    }

    public static <E extends Enum<E>> E deserialize(Class<E> enumType, String dbVal) {
        // possibly handle unknown values, below throws IllegalArgEx
        return Enum.valueOf(enumType, dbVal.trim());
    }

    // Sample use:
    String dbVal = getSerializedForm(Suit.SPADE);
    // save dbVal to db in larger insert/update ...
    Suit suit = deserialize(Suit.class, dbVal);