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

У меня есть простые отношения наследования в моем проекте, и я хотел бы, чтобы суперкласс был абстрактным. Некоторым классам-наследникам потребуется дополнительная информация о базе данных, а другим — нет. Я не уверен, какую стратегию наследования использовать.

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

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

Я действительно не хочу иметь лишние таблицы без причины, поэтому TABLE_PER_CLASS неуместен.

Я был бы признателен за любое руководство.

Спасибо


java hibernate inheritance jpa hibernate-annotations
person idbentley    schedule 31.03.2011    source источник

Ответы (2)


arrow_upward
3
arrow_downward

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

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

person Stefan Kendall    schedule 31.03.2011
comment
Спасибо! Это то, о чем я думал, но я все еще не уверен, что стратегия JOINED может быть лучше. - person idbentley; 31.03.2011
comment
@Стефан, я очень рад твоему мнению. В проекте на работе использовалось наследование. Существует Master объект и около 17 объектов подкласса, потому что, хотя большинство полей данных похожи, каждый подкласс может иметь одно или два (иногда несколько больше) уникальных полей. Сначала это казалось правильным, пока я не столкнулся с такими проблемами, как разрешение пользователю изменить тип подкласса или просмотр 17 объединений в запросе, потому что есть 17 таблиц. Итак, вы думаете, что одна таблица с нулевыми значениями, где это уместно, была бы лучше? Я все еще новичок в ORM, но я думал об этом в глубине души. - person theblang; 01.06.2013

arrow_upward
0
arrow_downward

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

Используйте стратегию SingleTable, и если вы считаете, что один из подклассов имеет большее количество полей и нуждается в отдельной таблице, затем отметьте этот подкласс как SecondaryTable, используя аннотацию @SecondaryTable, и используйте PrimaryKeyJoin (для этого есть аннотация), чтобы присоединиться к суперклассу на пк колонка. Кроме того, все поля в подклассе должны быть явно сопоставлены с вторичной таблицей с использованием атрибута «таблица» в аннотации @column.

person Sampath Pasupunuri    schedule 18.07.2013