Отображение наследования

• таблица для конкретного класса с неявным полиморфизмом
• таблица для конкретного класса с объединениями
• таблица для иерархии классов
• таблица для каждого подкласса

У нас есть супер класс BillingDetails в котором храниться пользователь, его персональный счет и дата создания. От этого класса наследуются два других класса: CreditCard и BankAccount. У каждого свои поля.

Каждый из шаблонов представленных ранее имееют свои преимущества и недостатки.

Шаблон «Таблица для конкретного класса»

Представляет иерархию наследования классов, используя по одной таблице для каждого конкретного класса этой иерархии.

Преимущества:

• каждая таблица замкнутая и не содержит ненужных полей. То есть у нас нет первичных полей, у нас все поля относятся к конкретному объекту. Получается, что когда нам нужно выбрать объект CreditCard мы получаем список всех его полей. Hibernate иницилизирует список своих полей, полей супер класса, если хотим, то используем его как супер класс, как отдельный объект. То есть мы одним запросом получаем наши собственные поля и в таблице нет ничего лишнего. Получается, что при доступе к классу мы получаем доступ к конкретной таблице. Если нам нужно сделать блокировку на запись, то мы делаем это для одной таблицы. Получается, что мы можем паралельно изменять информацию визитной карточки и информацию bankaccount, можно паралельно менять эти две записи. Одна блокировка в одном месте, другая в другом: они не зависимы друго от друга.
• при считывании данных не нужно выполнять соединений
• доступ к таблице только в случае доступа к конкретному классу

Недостатки:

• сложность реализации полиморфных связей, запросов, навигации. Это самый большой недостаток. Представим, что какой-нибудь другой класс, например, User. User ссылается на BillingDetails: получается полиморфная связь. Суть: выбрать все BillingDetails для конкретного пользователя. Сначала выполняем запрос к creditcard, затем к bankaccount. Мы собираем всю информацию с этих таблиц, но по сути нам нужны только первые три поля. Получается, когда мы делаем полиморфный запрос, то выполняется несколько запросов для каджого нашего подкласса. Также если мы обращаемся к BillingDetails, то автоматически будет обращение ко всем нижестоящим классам.
• изменение полей суперклассов требует изменения нескольких таблиц. Если мы начинаем менять поля суперкласса, то приходится эти поля менять в каждой из таблиц. Мы меняем структуру каждой таблицы. Изменение одной таблицы ведет к изменению других таблиц.

В данном случае иерархия классов в базе данных представляется таким образом, что для каждого конкретного класса, то есть те которые находятся на самом низу иерархии. Создается своя таблица и в эту таблицу перегоняются все собственные поля и все поля верхних классов (родителей). То есть для каждого не абстрактного класса создаем свою таблицу.

У нас есть три объекта и в базе мы получим две таблицы CREDIT_CARD, BANK_ACCOUNT. В каждой таблице будут дублироваться поля, которые мы взяли у супер класса и дальше будут собственные поля. Это самый простой способ реализации наследования.

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

Пример, класс DomainObject, содержит только одно поле - id и от этого класса наследуются все Entity. Id присутствует в каждой таблице как и в супер классе. Это по сути наш шаблон. Почему он здесь использован? Полиморфные запросы мы здесь вряд ли будет делать, нам вряд ли нужно будет получать все DomainObject. Зачем? Нам нужно получить либо все категории, всех пользователей и DomainObject-ты нам вряд ли когда понадобятся. Плюс, в DomainObject других полей вставлять тоже не будем.

В JPA есть две реализации этого шаблона.

Таблица для конкретного класса с неявным полиморфизмом

Если мы ставим аннотацию @MappedSuperclass, то все подклассы будут иметь поля суперкласса, их даже не нужно прописывать.

То есть если будет полиморфный запрос, то будут делаться запросы к подклассам.

Таблица для конкретного класса с объединениями

Структура таблиц такая же. При полиморфных запросах Hibernate будет использовать SQL операцию UNION и только один SELECT. За один UNION мы получим полиморфный ответ объект. Но остается проблема навигации, то есть когда мы получим доступ к конкретному BillingDetails Hibernate нужно будет сделать дополнительный запрос, узнавая к какому же он классу относится и вытащить дополнительные поля. То есть, проблема с навигацией остается, проблема с изменением схемы данных при добавлении новых полей тоже остается, но зато полиморфизм немного улучшаем.

Шаблон «Таблица для иерархии классов»

Представляет иерархию наследования классов в виде одной таблицы, столбцы которой соответствуют всем полям классов, входящих в иерархию.

Преимущества:

• в структуру базы данных добавляется только одна таблица.
• для извлечения данных не нужно выполнять соединение (объединений). Извлечение данных происходит очень быстро.
• изменение полей суперклассов и подклассов НЕ требует изменения нескольких таблиц. Если мы начнем перемещать поля из суперкласса в другое место, то схема базы все равно не меняется. При добавлении поля изменения вносятся только в одну таблицу.

Недостатки:

• Проблема NOT-NULL полей. Когда мы в таблиуц сохраняем bankaccount, что делать с поями, которые относятся к визитной карточке? Поля ведь остаются пустыми. А что если по логике приложения, в полях не должно быть NULL, например, номер кредитной карты всегда должен существовать.
• Проблемы параллельного считывания и блокировок. Соответственно, когда мы захотим измененить информацию о bankaccount мы блокируем информацию о кредитной карте и никто ее видеть не сможет.
• Пустое место в неиспользуемых столбцах. Пусто место, оно все равно есть и при больших объемах работы могут возникнуть трудности. База расрастается из-за пустого места.

В предыдущем шаблоне, на каждый класс была таблица, здесь одна таблица на всю иерархию. Здесь создается одна таблица и в ней перечисляются все поля (супер класса и подклассов). То есть одна большая таблица со множеством колонок.

Применять этот шаблон лучше там, где маленькая иерархия классов (максимум 3). Когда в наших подклассах храниться очень мало полей. Максимум полей выносим в суперкласс, а в подклассах по одному. Плюс здесь в скорости.

Для этого шаблона, так как одна таблица, нужно хранить информацию о том, какие колонки к какому классу относятся.

Дополнительная колонка которая будет отвечать что и куда называется Discriminator.

Шаблон «Таблица для каждого подкласса»

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

Преимущества:

• простая взимосвязь между моделью домена и схемой БД
• простота реализации полиморфных связей, запросов
• таблицы не занимают лишнего места
• реляционная модель полностью нормализована

Недостатки:

• загрузка объектов требует соединения таблиц
• перемещение полей из подкласса в суперкласс требует изменения структуры БД
• частый доступ к таблицам суперклассов

Первый шаблон - таблица для конкретного класса (абстрактные не храняться), второй шаблон - таблица на всю иерархию, третий шаблон - таблица создается для каджого класса иерархии (даже для абстрактного).

Создается BillingDetails с полями, и по таблице для CREDIT_CARD и BANK_ACCOUNT (в них хранятся только их собственные поля). Первичные ключи этих таблиц будут ссылаться на первичный ключ BillingDetails. Связь здесь происходит по первичным ключам.

Мы сохраненяем в базу конкретные объекты (абстрактные классы ведь не хранятся). Поэтому сохраняя BankAccount создается одна запись в BillingDetails и одна запись в BankAccount. То есть мы можем по первичному ключу их соединить.