Я бы сказал, что единственный безопасный механизм здесь - использовать значение String name(). При записи в БД вы мог используете sproc для вставки значения, а при чтении используете View. Таким образом, если перечисления изменяются, существует уровень косвенности в sproc / view, чтобы иметь возможность представить данные как значение перечисления без «навязывания» этого БД.

Мы никогда больше храним перечисления как числовые порядковые значения; это затрудняет отладку и поддержку. Мы сохраняем фактическое значение перечисления, преобразованное в строку:

public enum Suit { Spade, Heart, Diamond, Club }

Suit theSuit = Suit.Heart;

szQuery = "INSERT INTO Customers (Name, Suit) " +
          "VALUES ('Ian Boyd', %s)".format(theSuit.name());

а затем прочитайте:

Suit theSuit = Suit.valueOf(reader["Suit"]);

Проблема заключалась в том, что раньше смотрели на Enterprise Manager и пытались расшифровать:

Name                Suit
==================  ==========
Shelby Jackson      2
Ian Boyd            1

стихи

Name                Suit
==================  ==========
Shelby Jackson      Diamond
Ian Boyd            Heart

последнее намного проще. Первый требовал доступа к исходному коду и нахождения числовых значений, которые были присвоены членам перечисления.

Да, он занимает больше места, но имена членов перечисления короткие, а жесткие диски дешевы, и гораздо больше стоит помочь, когда у вас возникнут проблемы.

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

public enum Suit { Unknown, Heart, Club, Diamond, Spade }

должно было стать:

public enum Suit { 
      Unknown = 4,
      Heart = 1,
      Club = 3,
      Diamond = 2,
      Spade = 0 }

чтобы сохранить прежние числовые значения, хранящиеся в базе данных.

Как их отсортировать в базе

Возникает вопрос: допустим, я хотел упорядочить значения. Некоторые люди могут захотеть отсортировать их по порядковому номеру перечисления. Конечно, упорядочивать карты по числовому значению перечисления бессмысленно:

SELECT Suit FROM Cards
ORDER BY SuitID; --where SuitID is integer value(4,1,3,2,0)

Suit
------
Spade
Heart
Diamond
Club
Unknown

Это не тот порядок, который нам нужен - мы хотим, чтобы они располагались в порядке перечисления:

SELECT Suit FROM Cards
ORDER BY CASE SuitID OF
    WHEN 4 THEN 0 --Unknown first
    WHEN 1 THEN 1 --Heart
    WHEN 3 THEN 2 --Club
    WHEN 2 THEN 3 --Diamond
    WHEN 0 THEN 4 --Spade
    ELSE 999 END

Та же работа, которая требуется при сохранении целочисленных значений, требуется при сохранении строк:

SELECT Suit FROM Cards
ORDER BY Suit; --where Suit is an enum name

Suit
-------
Club
Diamond
Heart
Spade
Unknown

Но это не тот порядок, который нам нужен - мы хотим, чтобы они были в порядке перечисления:

SELECT Suit FROM Cards
ORDER BY CASE Suit OF
    WHEN 'Unknown' THEN 0
    WHEN 'Heart'   THEN 1
    WHEN 'Club'    THEN 2
    WHEN 'Diamond' THEN 3
    WHEN 'Space'   THEN 4
    ELSE 999 END

Я считаю, что такое ранжирование относится к пользовательскому интерфейсу. Если вы сортируете элементы на основе их значения перечисления: вы делаете что-то не так.

Но если бы вы действительно этого хотели, я бы создал таблицу размеров Suits:

| Suit       | SuitID       | Rank          | Color  |
|------------|--------------|---------------|--------|
| Unknown    | 4            | 0             | NULL   |
| Heart      | 1            | 1             | Red    |
| Club       | 3            | 2             | Black  |
| Diamond    | 2            | 3             | Red    |
| Spade      | 0            | 4             | Black  |

Таким образом, если вы хотите изменить свои карты для использования Поцелуи королей Новый порядок колоды, вы можете изменить его для отображения, не выбрасывая все свои данные:

| Suit       | SuitID       | Rank          | Color  | CardOrder |
|------------|--------------|---------------|--------|-----------|
| Unknown    | 4            | 0             | NULL   | NULL      |
| Spade      | 0            | 1             | Black  | 1         |
| Diamond    | 2            | 2             | Red    | 1         |
| Club       | 3            | 3             | Black  | -1        |
| Heart      | 1            | 4             | Red    | -1        |

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

SELECT Cards.Suit 
FROM Cards
   INNER JOIN Suits ON Cards.Suit = Suits.Suit
ORDER BY Suits.Rank, 
   Card.Rank*Suits.CardOrder

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

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
}

Это означает, что вся ваша ложь будет неверно истолкована как «файл не найден».

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

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

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

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;
        }
    }
}

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

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

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

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

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

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

   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);

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

Таблица костюмов:

suit_id suit_name
1       Clubs
2       Hearts
3       Spades
4       Diamonds

Таблица игроков

player_name suit_id
Ian Boyd           4
Shelby Lake        2

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

Несколько значений с отношением ИЛИ для одного поля перечисления. Концепция .NET с хранением типов перечислений в базе данных, таких как byte или int, и использованием FlagsAttribute в вашем коде.

http://blogs.msdn.com/b/efdesign/archive/2011/06/29/enumeration-support-in-entity-framework.aspx

Весь мой опыт подсказывает мне, что самый безопасный способ сохранения перечислений в любом месте - это использовать дополнительное значение кода или идентификатор (своего рода эволюция ответа @jeebee). Это может быть хорошим примером идеи:

enum Race {
    HUMAN ("human"),
    ELF ("elf"),
    DWARF ("dwarf");

    private final String code;

    private Race(String code) {
        this.code = code;
    }

    public String getCode() {
        return code;
    }
}

Теперь вы можете использовать любое постоянство, ссылаясь на константы перечисления по коду. Даже если вы решите изменить некоторые имена констант, вы всегда можете сохранить значение кода (например, с DWARF("dwarf") на GNOME("dwarf")).

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

interface CodeValue {
    String getCode();
}

И пусть наше перечисление реализует это:

enum Race implement CodeValue {...}

Пришло время магического метода поиска:

static <T extends Enum & CodeValue> T resolveByCode(Class<T> enumClass, String code) {
    T[] enumConstants = enumClass.getEnumConstants();
    for (T entry : enumConstants) {
        if (entry.getCode().equals(code)) return entry;
    }
    // In case we failed to find it, return null.
    // I'd recommend you make some log record here to get notified about wrong logic, perhaps.
    return null;
}

И используйте его как амулет: Race race = resolveByCode(Race.class, "elf")

Я столкнулся с той же проблемой, когда моя цель - сохранить значение Enum String в базе данных вместо порядкового значения.

Чтобы решить эту проблему, я использовал @Enumerated(EnumType.STRING), и моя цель была решена.

Например, у вас есть класс Enum:

public enum FurthitMethod {

    Apple,
    Orange,
    Lemon
}

В классе сущности определите @Enumerated(EnumType.STRING):

@Enumerated(EnumType.STRING)
@Column(name = "Fruits")
public FurthitMethod getFuritMethod() {
    return fruitMethod;
}

public void setFruitMethod(FurthitMethod authenticationMethod) {
    this.fruitMethod= fruitMethod;
}

Пока вы пытаетесь установить значение в базу данных, строковое значение будет сохранено в базе данных как «APPLE», «ORANGE» или «LEMON».

Вы можете использовать дополнительное значение в константе перечисления, которое может выжить как при изменении имени, так и при обращении к перечислениям:

public enum MyEnum {
    MyFirstValue(10),
    MyFirstAndAHalfValue(15),
    MySecondValue(20);

    public int getId() {
        return id;
    }
    public static MyEnum of(int id) {
        for (MyEnum e : values()) {
            if (id == e.id) {
                return e;
            }
        }
        return null;
    }
    MyEnum(int id) {
        this.id = id;
    }
    private final int id;
}

Чтобы получить идентификатор из перечисления:

int id = MyFirstValue.getId();

Чтобы получить перечисление из идентификатора:

MyEnum e = MyEnum.of(id);

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

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

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

Чтобы исправить это, вы также можете настроить таблицу с идентификаторами перечислений в базе данных. Или пойти другим путем и выбрать идентификаторы перечислений из таблицы по мере добавления в нее строк.

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