У меня возникли проблемы с решением, как сопоставить данные ключа / значения с сущностью разумным и эффективным способом.Я мог бы даже ошибиться, поэтому я благодарен за любые подсказки.
В основном речь идет о связывании различных общих атрибутов с сущностью объекта недвижимости, например:
- Лифт: да / нет (логическое)
- спальни: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, была бы более подходящей, но, к сожалению, сейчас это не вариант.