[Из песочницы] Наследование в Hibernate: выбор стратегии

Комментарии 4

  • 08.09.17 в 16:38

    0

    Наследование на уровне SQL красиво и ИМХО правильно реализуется примерно так же, как оно физически реализовано в объектно-ориентированных языках программирования. Класс-родитель представляется в виде первой таблицы, класс-потомок представляется в виде второй таблицы с отношением один-к-одному к первой. Унаследованные поля/свойства хранит в первой таблице, новые — во второй.
    • 08.09.17 в 16:53

      0

      Добрый день!
      В принципе, Вы правы. Об этом как раз говорится здесь:
      Стратегия №4 (JOINED) подойдет в случаях, когда требуются полиморфные запросы и ассоциации, но подклассы объявляют относительно много новых полей.

      Другое дело, что если их нет, то нет и особого смысла выбирать «заточенную» под них стратегию JOINED, при наличии более выигрышных в плане производительности вариантов.
  • 9130eb3ba6c60bf548a9f7ab4703e68e_small.j

    08.09.17 в 19:11

    0

    Странно, почему нет смешанной стратегии JOINED и SINGLE_TABLE. Родительская таблица содержит поля первичного ключа, дискриминатор и поля нагрузки. Дочерние таблицы — поля первичного ключа и поля своей нагрузки.


    Как я понимаю, основной недостаток JOINED — когда и нас десятки классов в иерархии, соединяться будут все десятки таблиц только ради того, чтобы выяснить для каждой строки, откуда брать данные.

  • d781f090da1b6e4a3795971b1f50d52d_small.j

    08.09.17 в 19:23

    0

    Мне лично не понятны не стратегии, а как дальше работать с наследуемыми entity.
    Например, как определить Spring’овый JPA Repository для BillingDetails в данном случае?

    Или как определить класс Payment со связью к BankAccount или CreditCard?

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

© Habrahabr.ru