В Concrete table inheritance(в хибере это НЕ дефолт) для каждого конкретного класса иерархии создаётся таблица БД со всем полями класса и всех его предков.

Фаулер пишет, что при таком раскладе во всех таблицах должны использоваться идентификаторы уникальные в рамках иерархии

Теперь про проблему:

Есть иерархия наследования:


игрок <== футболист
-------- <== баскетболист

В итоге в базе 2 таблицы футболист и баскетболист

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

Автор пишет, что одно из решений это сделать таблицу связку для каждой таблицы соответсвующей конкретному класса(футболист, баскетболист), но по очевидным причинам это не очень эффективно. А какие-то ещё есть варианты?

Я из текста вообще не понял когда такой подход будет хорош.

также вызывает вопросы следузщее утверждение:


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

спортcмен(Абстрактный класс)<==== конькобежец(конкретный класс)<===== хоккеист(конкретный класс)


итого имеем 2 таблицы для конькобежцев и для хоккеистов

1. переместили поле из спортсмена в конькобежца

Вроде никаких изменений в таблице не надо делать

2. переместили поле из конькобежца в хоккеиста

таблица хоккеиста остаётся неизменной

из конькобежца вырезаем поле

3. переместили поле из хоккеиста в конькобежца

добавляем поле в конькобежца

таблица хоккеиста остаётся неизменной

4. переместили поле из конькобежца в спортcмена

ничего не делаем

То есть что-то меняется только для конкретных классов, которые не являются листьями. Правильно я понял?

PetroNotC SharpquestionerТеперь про проблему:то есть для умолчания в хибере проблемы не будет?
Почему не рассмотрели?

По умолчанию не будет. Что рассмотреть? вообще вопрос не по существу.

PetroNotC SharpquestionerЯ из текста вообще не понял когда такой подход будет хорош.вы с фаулером втыкаете наследование в рсубд.
Это вообще не есть хорошо. Поэтому и компромиссы и костыли и куча вопросов.

Вопросы предполагают ответы. В данном топике обсуждаются конкретные вопросы.

PetroNotC SharpquestionerВ Concrete table inheritance(в хибере это НЕ дефолт)это плохой метод.
Зачем его обсуждать?

Фаулер такого не написал. Из текста мне тоже показалось, что это не лучшее решение, но сорян, где ты, где я и где Фаулер.

PetroNotC Sharpquestioner,
Правильно я понял, что мне нужно обосновать выключение основного режима хибера?
При котором он эффективнее работает?

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

PetroNotC Sharpquestioner,
Это как в школе вопрос:
- На чем поедешь?
- На машине!
- Машина сломалась.
- Тогда пешком!
- Ног нету....
- Тогда поползу!
....
))))

Твоё умение что-то брякнуть, даже если сказать нечего - поражает.

PetroNotC SharpquestionerТвоё умение что-то брякнуть, даже если сказать нечего - поражает.
Вот у тебя - смотрю в книгу, вижу фигу лучше?

Так я и пришёл с посылом, что вот я не понимаю - объясните, пожалуйста те, кто может. Почему отвечает только тот, кто не может - не поддаётся объяснению.

Kachalov- Вам надо три таблицы, еще и родительскую "игрок"


Не надо по этому типовому решению. тут только для конкретных классов требуется таблица

KachalovquestionerНе надо по этому типовому решению. тут только для конкретных классов требуется таблица
- пожалуйста, Вам видней

В этом и суть вопроса просто)

Kachalovasv79дядь ты бы изучил для начала hibernate inheritance
если делать три таблицы,тогда нахрен вообще это свойство хибера))

суть этого действа в том,что ты определяешь в супер классе общие поля,а в налслдниках частные и при создании новой сущности автоматически производится запись в той табле,к которой принадлежит сущность
- парниш, клал я на твой хибер. Или Фаулер - это специалист по Хиберу?

- а по существу: надо быть имбецилом, чтобы дублировать в таблицах поля, которые можно держать в одной таблице. Как минимум с точки зрения ООП это будет кретинизмом. С точки зрения РСУБД вопрос не однозначный - может быть лучше, может быть хуже, в зависимости от того какие запросы выполняются.

о, эксперты подтянулись)

maytonquestioner, давай приводи полную цитату Фаулера. А то получается как в анекдоте
про Рабиновича который Шаляпина напел.

завтра закину фотку книги, а то чего-то совсем не в ту степь ответы.

Kachalov,
не благодари: https://habr.com/ru/post/337488/

В хибере кстати ещё 4-ая какая-то стратегия есть дополнительная относительно Фаулера - надо почитать.

Kachalovasv79ты попробуй это руками настучи и поймешь как это круто,хотя тут многие против inheritance
- вероятно Вы не знаете про то что стратегий наследования в JPA (или на понятном Вам языке - в Хибере) три: TABLE_PER_CLASS, JOINED, SINGLE_TABLE. Лично я посоветовал ТСу JOINED, на мой взгляд, дублировать сложные отношения между таблицами хуже, чем лишние джойны, но ТСу видней (исходя из специфики и интенсивности запросов).


Во-первых 4 стратегии, Во-вторых вопрос ТС-а звучит как что хотел сказать автор(Фаулер)

забыл никquestionerпропущено...



Во-первых 4 стратегии, Во-вторых вопрос ТС-а звучит как что хотел сказать автор(Фаулер)
Так ему и пиши?

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

забыл никquestionerпропущено...


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

Если чуть изучить Герменевтику , то можно понять, что то что имел ввиду автор и что поняли прочитавшие - это как говорится две большие разницы. И если интересует мнение автора - смотри мой совет выше. Если интересует все же комьюнити(частью которого и являются мемберы sql.ru) - то нефиг вякать.

Если по делу, то вся эта глава безнадежно устарела, но не в смысле теории а в смысле применения - никто в здравом уме не будет мапить наследование в БД. Поэтому знание этого = шлак, хочешь копаться в навозе - почитай спеки EJB 1.0, вот там веселье будет гарантированно.


Устарела настолько, что Хибер использует эти стратегии. Фаулер про фундаментальные вещи пишет.

забыл никНу и я мапил лет так 8 назад. А сейчас бы взял MongoDB и не парился


Аргумент, ничего не скажешь

PetroNotC SharpKachalovТС конкретная проблема или он интересуется тем о чем думал Фаулер когда описывал паттерн?именно думал).
ТС сам код не пишет. Теоретизирует.

Ты то тот ещё писатель. Вот скажи, Петрович, ты когда книгу читаешь, в которой автор код не написал будешь пытаться написать код? не думал ли ты, что если автор не включил код, то значит он не очень то и нужен?

maytonquestioner, давай приводи полную цитату Фаулера. А то получается как в анекдоте
про Рабиновича который Шаляпина напел.

PetroNotC Sharpquestioner,
И что непонятного в красном?
В базе нельзя контролировать целостность FK так как инфа разбросана по таблицам.

Ну то есть он просто имеет ввиду, что такую ситуацию при таком маппинге тяжело хендлиьт и получается какое-то говно?

PetroNotC Теперь приводи не объектную модель, а модель физическую в бд.

А чего приводить то - таблицы только для конкрентных классов (футболистов и крикетистов)