Deka007: наследование отличается тем, что подразумевается выделение отдельной сущности, при агрегации сущность содержит в себе элементы, без которых может существовать. Например, аквариум без рыб может существовать, а вот при композиции, например, рок-группа не может существовать без ее участников
Денис Загаевский: решение данной задачи вообще не толкает ни на какой путь, а лишь точно дает ответ на вопрос. Придет время и ТС сам для себя решит что и как лучше делать (начиная с уровня архитектуры), а пока это пустые советы под проявлением занудства или "бомбежки"
во время пика пользователю лень ввести больше, чем "lua", да и такой большой процент был тех, кто задумав искать "супер луну" решил все же посмотреть о ЯП (как понял поисковик они именно ЯП и имели в виду)
П.С. Кроме авто на первой странице по запросу "Tesla" нет Николы((
Владимир Смирнов: сколько текста и не по теме. Какая еще мешанина? Я все четко описал. JOIN'ы берутся тогда, когда нужно получить не только записи определенного FieldType (Slider, Date...) , а все записи Field независимо от типа
Владимир Смирнов: например когда у меня будет 10 разных таблиц с 4 одинаковыми и 3 своими полями.
При одном Entity и дополнительном Embedable будет один JOIN, а вот при выделенном Entity на каждый тип будет беда из 10 JOIN-ов, разве что если это все в одном поле, тогда базе придется пробежаться по 4+3*10=34 полям, большая часть из которых NULL.
Конечно, последний способ лучше, чем второй, но вот попроще реализовать первый не дает Hibernate, так как ему нужен только экземпляр класса Field, а не от него наследуемый. В общем это решается копированием в Field, но сказывается на лишнем вызове метода
То есть сам SliderField в persist не принимает, нужно делать slider.getField()
Владимир Смирнов: да, именно эти два случая (как отдельные таблицы, так и много-много полей в одной таблице). Это та структура, которая не приемлема, с этим уже определился, и вывод только один - нужна одна таблица Field и дополнительная для дополнительных полей, в этом то вся и соль Hibernate, что он слишком абстрагирует
Владимир Смирнов: спасибо за ненужный совет, уже работал с тем что попроще. Вопрос был в том, как эти данные из предложенного выше примера хранятся в одной таблице, если есть отличающиеся поля их тех Entity
Владимир Смирнов: если делать их отдельными Entity, но это получится не хорошо со стороны структуры БД, так как сами сущности этих типов равноправны и должны все вместе выводиться списком, а если они будут раскиданы на несколько таблиц, то это будет много JOIN'ов
