Комментарии 12
В принципе, Вы правы. Об этом как раз говорится здесь:
Стратегия №4 (JOINED) подойдет в случаях, когда требуются полиморфные запросы и ассоциации, но подклассы объявляют относительно много новых полей.
Другое дело, что если их нет, то нет и особого смысла выбирать «заточенную» под них стратегию JOINED, при наличии более выигрышных в плане производительности вариантов.
Странно, почему нет смешанной стратегии JOINED и SINGLE_TABLE. Родительская таблица содержит поля первичного ключа, дискриминатор и поля нагрузки. Дочерние таблицы — поля первичного ключа и поля своей нагрузки.
Как я понимаю, основной недостаток JOINED — когда и нас десятки классов в иерархии, соединяться будут все десятки таблиц только ради того, чтобы выяснить для каждой строки, откуда брать данные.
Как я понимаю, основной недостаток JOINED — когда и нас десятки классов в иерархии
Так и есть, но модель данных обычно не имеет зверских иерархий, там как правило один (а чаще, пожалуй, вообще ноль), ну максимум два уровня наследования.
Ну количество таблиц-то зависит не только от глубины дерева наследования, но и его ширины. У вас может быть один суперкласс и десятки его прямых потомков. Мне кажется, вполне не редкая ситуация, особенно, если в этом месте система предполагает расширяемость (добавление новых классов). И при каждой выборке объектов суперкласса придется джойнить все эти таблицы. Надо надеяться, в Hibernate есть оптимизации, когда он не джойнит заведомо ненужные "братские" таблицы, если выбираем какого-то потомка.
Например, как определить Spring'овый JPA Repository для BillingDetails в данном случае?
Или как определить класс Payment со связью к BankAccount или CreditCard?
Например, вот так:
Пример не связан с исходниками статьи, но суть понятна. Используя SpEL, указываете в Query нужную реализацию User'a, которая и будет выступать в качестве T.
Как насчет самого простого варианта?
"0. Не используйте наследование реализаций для объектов, отображаемых на базу данных."
Наследование в Hibernate: выбор стратегии