Таблица для подкласса Vs Таблица Для конкретного класса в спящем режиме?

В большинстве веб-приложений я видел один базовый класс, состоящий из общих свойств и количества подклассов, расширяющих базовый класс. Поэтому мой вопрос заключается в том, какую стратегию мы должны использовать для Таблица для подкласса Vs Table В конкретном классе. Я лично считаю, что мы должны идти за таблицей на подкласс, потому что в будущем, если мы хотим ввести общий столбец, мы можем сделать это в одном месте, но в случае конкретного класса мы должны сделать это в нескольких таблицах. Right?

Но да, если мы хотим извлечь все деатили из всех дочерних таблиц, я думаю, что Таблица для конкретного класса будет полезна, потому что нам нужно просто объединить записи из всех таблиц, но в случае Таблица в классе Sub вместе с объединением мы должны ввести соединение с родительской таблицей, которое будет более дорогостоящим. Правильно?

Ответ 1

Вам может быть интересен раздел 2.12 "Стратегии сопоставления наследования" спецификации JPA 2.0, так как он суммирует все возможные типы наследования, а также их преимущества и недостатки, Позвольте мне вытащить только самые интересные фрагменты:

2.12.1 Стратегия иерархии отдельных таблиц в классе

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

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

Эта стратегия имеет следующие недостатки:
- Он обеспечивает плохой поддержку полиморфных отношений.
- Обычно для запросов, которые предназначены для диапазона по иерархии классов, требуется, чтобы были запрошены SQL UNION запросы (или отдельный запрос SQL для каждого подкласса).

2.12.2 Присоединительная стратегия подкласса

У него есть недостаток, который требует, чтобы одна или несколько операций объединениявыполняться для создания экземпляров подкласса. В глубоком классе иерархии, это может привести к неприемлемой производительности. Запросы, которые диапазон по иерархии классов также требует объединения.

Кроме того, если вы планируете поддерживать JPA-совместимость, помните, что JPA-провайдер не должен поддерживать TABLE_PER_CLASS тип стратегии.

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

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

Надеюсь, что это поможет!

Ответ 2

Несоответствие объектно-реляционного импеданса

В объектной модели при создании объекта нам может потребоваться использовать наследование, т.е. обобщение, следующим образом:

В реляционной модели указанное выше Обобщение может быть достигнуто в Hibernate ORM со следующими тремя стратегиями сопоставления наследования:

Таблица для иерархии
Таблица Per Concrete class
Таблица для подкласса

В этой стратегии мы можем отобразить всю иерархию в одну таблицу, здесь мы используем еще один столбец дискриминатора, т.е. ТИП.

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

В этой стратегии таблицы создаются в соответствии с классом, но связаны с внешним ключом. Таким образом, дубликатов столбцов нет.

источник изображения