Добрый день. Есть БД из трех таблиц:


Для всех таблиц id - суррогатный первичный ключ. В таблице T3 ref_id ссылается на поля id таблицы T1 или T2. ref_type - обозначает, на какую именно таблицу ссылается ref_id. При этом T1 и Т2 отражают сущности предметной области, их тип (на который ссылается Т3.ref_type) известен только на уровне приложения, в таблицах (Т1, Т2) он не хранится. Т3 - не является сущностью, это своего рода результат деятельности. Пример: простейший учет невыходов на работу. Пусть Т1 отражает прогулы, Т2 - больничные. Пусть они оба содержат дату начала и окончания события, а в таблицу Т3 пишут количество дней прогула/больничного. Тогда Т3 позволит получить общее количество дней отсутствия на работе.
Вопросы: Можно ли такое поведение (получение сущностей Т1 и Т2 с коллекциями их записей из Т3 ) замапить аннотациями JPA/Hibernate? Какая альтернатива может быть такой схеме при условии сохранения функционала?

Blazkowicz, большое спасибо за ответ. О таком варианте я думал, в итоге я получу Т3 с FK на Т4 через ref_id, без использования doc_id. То есть фактически, буду иметь возможность по ссылке на экземпляр Т1 или Т2 вытянуть все связанные с ними записи из Т3. Это очень хорошо. Но, я буду лишен возможности анализировать саму Т3 на предмет того, к какому типу относятся записи в ней. Я не смогу сказать - эти записи класса Т2, вот эти - класса Т1. Или, на моем примере, не смогу отделить больничные от прогулов.

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

Blazkowicz, как это сделать?

Petro123, с одной таблицей я не выкручусь. Даже если пойду от сущности "Документ". Их может быть не 2 а 20, и все с разными полями, общие у них конечно будут, типа дата документа, комментарий, еще что-нибудь в этом духе. А относиться они могут при этом к одной области, и вычислять значения, которые мне нужно хранить в Т3 как им вздумается. Их объединяет не общая структура, а общий результат - который мне нужно хранить в Т3.

Blazkowicz, у меня база с вариантами. Я ищу вариант, с которым мне будет удобнее работать, и который можно будет безболезненно расширить при появлении новых сущностей типа Т1 и Т2

Petro123, у меня от базы. От базы, которой еще нет. В моей предметной области происходят события, эти события регистрируются документами. То есть как минимум у меня будет по одной таблице на каждый вид регистрируемого события. Делать одну таблицу с типом события не могу, потому что у документов может быть сильно разная структура. Кроме собственно регистрации события, на основании данных документа будут произведены некоторые вычисления, и результаты вычислений мне нужно будет хранить в еще одной таблице. При этом туда свои вычисления могут складывать разные документы. Сколько их будет, я пока не знаю. Поэтому мне нужна ссылка на документ и на его тип в этой таблице. Еще один важный момент. Я хочу иметь возможность включать/выключать отражение вычислений документа. То есть его родную таблицу не трогаю, но при необходимости удаляю/записываю его вычисления в таблицу результатов вычислений. Отчеты я буду строить по таблице результатов, и никогда не буду трогать сами таблицы документов.

Petro123, первичен документ, эта идея именно из 1С, уж очень мне понравились их мысли по поводу регистров сведений/накопления. С хибером дружить хочу, попробовал зайти со стороны классов. То есть позволить хиберу создать схему базы данных по моим аннотированным классам (Документы разные - то что они навычисляли имеет одинаковый формат). Вот классы (геттеры, сеттеры, методы опущены):




По такому определению хибер генерирует схему, привязывая каждый Doc к Reg через вспомогательную таблицу. На уровне классов я конечно могу найти соответствие между doc и его Reg. Но отчеты я буду строить не вытаскивая из базы каждую строчку в новый объект, а обычными запросами и обработкой результата. И там опять же я не имею в таблице Reg ссылки на тип документа, который породил запись. В одинэсе такая возможность есть.

Petro123, тут еще идеологический вопрос. Все-таки документы (Т1,Т2 или Doc1, Doc2) это сущности, а их результаты (T3, Reg) - нет. А по классам получается что сущности и те и другие. Может у хибернейта есть что-нибудь на этот счет?

Blazkowicz, подумал присмотреться к этому поближе:авторстранная у вас и не нормализованая структура. но она легко исправляется введением дополнительноый таблицы T4 для хранения всех PK.

T1 и T2 имеют PK, который так же является FK на T4.
T3 ссылается на T4. Таким образом на ref_id можно смело навесить FK constraint.

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

В этом случае констрейнты слишком сильные, или я чего-то недопонял. Если у Т4 (doc_reg на схеме) будут FK и на T1(Doc1) и на T2(Doc2), то в нее можно будет писать только Id, которые есть сразу в обеих таблицах T1 и T2. То есть если у меня в T1 есть айди (1,2,3) а в T2(4,5,6), то я не смогу в T4 записать ни то ни другое.

Blazkowicz, Я в таком случае совершенно запутался. Если FK должен быть с другой стороны, то doc_id В Т4(doc_reg) должно быть уникально, а оно не может, потому что Т1 и Т2 могут быть одинаковые идентификаторы.

Blazkowicz, может тогда лучше взять sequence и назначить его для генерации id T1 и T2 и вообще не использовать T4? У меня Postgres, вроде бы он такое позволяет

Blazkowicz, шах и мат. Если приходится делать такое на несложной в принципе базе:
авторНужно просто INSERT реализовать так, чтобы после вставки в T4, тот же самый ID использовался в T1 или T2. В них не будет автоинкремента. Они просто будут использовать значение PK из T4 для собственнй PK+FK колонки. Hibernate такое умеет.
значит с базой что-то явно не в порядке, буду думать что-то более вменяемое. Хибернейт наверняка умеет, но я еще не скоро научусь делать такое. Очередной, и боюсь не последний раз, благодарю за консультацию.

Blazkowicz, да, я писал уже про рыбку и сидение. Хочу возможности как в 1с (документ - регистр), но там даже не пахнет целостностью на уровне СУБД. А чтобы и функциональность получить ту же и согласованную базу без извращений и опирания на возможности конкретно хибернейта, буду "экскрементировать" дальше.