JPA: гибко отображает «атрибуты» (данные ключа / значения различных типов данных) на объект - PullRequest
3 голосов
/ 16 августа 2011

У меня возникли проблемы с решением, как сопоставить данные ключа / значения с сущностью разумным и эффективным способом.Я мог бы даже ошибиться, поэтому я благодарен за любые подсказки.

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

  • Лифт: да / нет (логическое)
  • спальни:2 (целое число)
  • обстановка: [полная |частичный |none] ("enum")
  • представление: текст произвольной формы (строка)

Атрибуты и их тип данных (строка, bool, целое число, "enum" - один выходиз числа заранее определенных строк) должны быть определены во время выполнения, т. е. храниться в базе данных.Тип атрибута также может содержать метаданные для генерации графического интерфейса (мин / макс / степпинг для int и т. Д.).Кроме того, должна быть возможность эффективно запросить любой набор комбинаций ключ / значение, то есть квартиру с более чем 2 спальнями, без мебели, с лифтом.

Я начал свой подход с объединенного наследования (упрощенный код):

@Entity
@Inheritance(strategy=InheritanceType.JOINED)
public class Attribute
{
    @Id
    public int attribute_id;
    public String name;
    public int type;
}

и производного класса для каждого вида атрибута:

@Entity
public class IntAttribute extends Attribute
{
    public int minvalue;
    public int maxvalue;
    public int stepping;
}

@Entity
public class EnumAttribute extends Attribute
{
    @OneToMany(...)
    public List<EnumAttributeValue> values = new ArrayList<EnumAttributeValue>();
}

Я скоро столкнулся сСтена с таким подходом, так как EnumAttribute не имеет каких-либо собственных свойств, кроме списка возможных значений, что означает, что у меня, вероятно, будет таблица enum_attribute, содержащая только attribute_id и ничего больше.То же самое с StringAttribute и BooleanAttribute, которые не имеют никаких свойств, которых еще нет в базовом классе Attribute.

Я также не совсем уверен, как бы я сопоставил фактическую пару ключ / значение с сущностью.Создать базовый класс AttributeValue и один для каждого типа данных?Попробуйте сделать плоскую иерархию TABLE_PER_CLASS для фактических значений для эффективного поиска?

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

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