|
|
|
Hibernate: Необычные связи. Можно и нужно ли так делать?
|
|||
|---|---|---|---|
|
#18+
javapeckerдолжно быть уникально, а оно не может, потому что Т1 и Т2 могут быть одинаковые идентификаторы. Это не обязательно. Нужно просто INSERT реализовать так, чтобы после вставки в T4, тот же самый ID использовался в T1 или T2. В них не будет автоинкремента. Они просто будут использовать значение PK из T4 для собственнй PK+FK колонки. Hibernate такое умеет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2012, 10:58:23 |
|
||
|
Hibernate: Необычные связи. Можно и нужно ли так делать?
|
|||
|---|---|---|---|
|
#18+
Blazkowicz, может тогда лучше взять sequence и назначить его для генерации id T1 и T2 и вообще не использовать T4? У меня Postgres, вроде бы он такое позволяет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2012, 11:02:14 |
|
||
|
Hibernate: Необычные связи. Можно и нужно ли так делать?
|
|||
|---|---|---|---|
|
#18+
javapeckerBlazkowicz, может тогда лучше взять sequence и назначить его для генерации id T1 и T2 и вообще не использовать T4? У меня Postgres, вроде бы он такое позволяет Тогда у вас не будет FK констрейнта в T3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2012, 11:03:22 |
|
||
|
Hibernate: Необычные связи. Можно и нужно ли так делать?
|
|||
|---|---|---|---|
|
#18+
Blazkowicz, шах и мат. Если приходится делать такое на несложной в принципе базе: авторНужно просто INSERT реализовать так, чтобы после вставки в T4, тот же самый ID использовался в T1 или T2. В них не будет автоинкремента. Они просто будут использовать значение PK из T4 для собственнй PK+FK колонки. Hibernate такое умеет. значит с базой что-то явно не в порядке, буду думать что-то более вменяемое. Хибернейт наверняка умеет, но я еще не скоро научусь делать такое. Очередной, и боюсь не последний раз, благодарю за консультацию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2012, 11:10:48 |
|
||
|
Hibernate: Необычные связи. Можно и нужно ли так делать?
|
|||
|---|---|---|---|
|
#18+
javapeckerBlazkowicz, шах и мат. Если приходится делать такое на несложной в принципе базе: значит с базой что-то явно не в порядке, буду думать что-то более вменяемое. Хибернейт наверняка умеет, но я еще не скоро научусь делать такое. Очередной, и боюсь не последний раз, благодарю за консультацию. Hibernate много чего умеет. Но безотносительно его, базу данных стоит проектировать так, чтобы гарантировать целостность данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2012, 11:13:51 |
|
||
|
Hibernate: Необычные связи. Можно и нужно ли так делать?
|
|||
|---|---|---|---|
|
#18+
Blazkowicz, да, я писал уже про рыбку и сидение. Хочу возможности как в 1с (документ - регистр), но там даже не пахнет целостностью на уровне СУБД. А чтобы и функциональность получить ту же и согласованную базу без извращений и опирания на возможности конкретно хибернейта, буду "экскрементировать" дальше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2012, 11:19:39 |
|
||
|
Hibernate: Необычные связи. Можно и нужно ли так делать?
|
|||
|---|---|---|---|
|
#18+
javapecker, чтобы гарантировать на уровне СУБД. Надо не сливать данные от разной БЛ-сущностей в одну таблицу. Тогда вьюшка объединяет и суммирует в представлении-слое. Но, понятно, что при использовании ОРМ (Хибер), ни о каком сильном контроле говорить не приходится. Контролирует Хибер. ------- С другой стороны, если у Вас есть Факты в таблице Т4 за прошлый год. И вы вдруг решили удалить Документы их родившие. То опять Вам решать как это будет происходить. В 1С это в БЛ сервисном проверяются все связи и даётся разрешение всё удалить..... ... Т.е. делается по разному - делайте как БЫСТРО-ПРОСТО-УДОБНО. Всё расно потом переделывать))) шутка)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2012, 11:54:09 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=37890198&tid=2131298]: |
0ms |
get settings: |
21ms |
get forum list: |
27ms |
check forum access: |
8ms |
check topic access: |
8ms |
track hit: |
59ms |
get topic data: |
20ms |
get forum data: |
4ms |
get page messages: |
80ms |
get tp. blocked users: |
3ms |
| others: | 343ms |
| total: | 573ms |

| 0 / 0 |
