Способы сохранения перечислений в базе данных

Question

Каков наилучший способ сохранить перечисления в базе данных?

Я знаю, что Java предоставляет name() и valueOf() методы для преобразования значений перечисления в строку и обратно. Но есть ли другие (гибкие) варианты для хранения этих значений?

Есть ли умный способ превратить перечисления в уникальные числа (ordinal() небезопасно для использования)?

Обновление:

Спасибо за все крутые и быстрые ответы! Это было, как я и подозревал.

Однако примечание к «инструментарию»; Это один из способов. Проблема в том, что мне нужно было бы добавлять одни и те же методы к каждому типу Enum, который я создаю. Это много дублированного кода, и на данный момент Java не поддерживает никаких решений для этого (перечисление Java не может расширять другие классы).

Answer 1

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

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  |

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

| 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

Answer 2

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

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

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) не зависят от значения перечисления, что также помогает вам работать с данными на других языках.

Answer 3

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

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

Но что произойдет, если вы обновите Boolean?

public enum Boolean {
    TRUE, FILE_NOT_FOUND, FALSE
}

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

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

Answer 4

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

Answer 5

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

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

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

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

Answer 6

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

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

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 был маленьким.

Answer 7

Я столкнулся с той же проблемой, когда моя цель - сохранить значение 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».

Answer 8

Весь мой опыт подсказывает, что самый безопасный способ сохранения перечислений в любом месте - это использовать дополнительное значение кода или id (своего рода эволюция ответа @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 реализует это:

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

Answer 9

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

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

Answer 10

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

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