|
|
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
javapeckerНе понимаю почему вдруг таблица телефонов стала главной. если в ТЗ вместо Телефона - Адрес, то БА может задать требования и делаем Модель по варианту 2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 13:52:06 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
Petro123, Я спрашиваю, почему в своем варианте ты называешь главной таблицу сотрудников, а во втором варианте главной - таблицу телефонов? База одинаковая в одном и другом случае. В приложении разница только в том, что в телефоне нет ссылки на сотрудника. В коде который ты выложил нет никаких ограничений, которые запретили бы создавать висячий телефон. В моем варианте их тоже нет, но если сделать так в твоем: Код: java 1. 2. или так в моем: Код: java 1. 2. 3. то ты не сможешь сохранять сиротливые телефоны и там и там. И все. по поводу этого: Нафига иметь телефонный номер в БД без сотрудника? Т.е. ничей? См. выше - установи ограничения. Есть они или нет - они одинаково работают для первого и второго варианта. Ну и кстати, а нафига мне иметь в телефонном номере ссылку на сотрудника? я нигде не буду пользоваться номером отдельно от сотрудника. И у меня навигация будет всегда от сотрудника к телефону, но не наоборот. Поэтому - второй вариант. И в твоем и в моем варианте связью нужно управлять, эмбед позволяет это делать автоматически без использования каскада. Поэтому еще лучше - третий вариант, потому что он гарантирует, что сиротливых телефонов не будет и они всегда будут синхронизированы с сотрудником. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 14:11:12 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
javapecker, не понятно, почему ты упорно пытаешься всю жизнь свести к одному варианту, одному маппингу и одной модели? Возьми Access и посмотри. Один ко многим: 1. Сотрудник ---> Заказы для Организации где плевать на заказы (удалять надо) 2. Сотрудник ---> Заказы для Организации с производством Товаров (удалять нельзя, т.к. они Главные) Будет 2 модели по Бизнесу, а также разный ГУИ! ОК? PS/ Каскад решает очень многое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 14:31:26 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
javapecker, давай, сделай примерчики, и завтра поковыряем демки и генерацию схемы хибером. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 14:33:48 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
Petro123, сделал под нетбинс 7.2+Postgres. В первых двух случаях схема генерится одинаковая. Висячие телефоны сохраняются. С добавлением optional = false или nullable = false не сохраняются. В третьем случае для телефона генерится таблица без первичного ключа с фк на сотрудника. Выложить проекты? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 14:37:16 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
javapeckerНу и кстати, а нафига мне иметь в телефонном номере ссылку на сотрудника? afaik на rsdn чел мучился именно с каскадом. У него не выходило именно без этой ссылки. Попробуй и выложи минимальный с каскадом для 1-го варианта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 14:38:31 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
javapecker, проекты не надо. Лучше как выше написал: 1. Каскад без висячих 2. без каскада + висячие само собой 3. без PK ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 14:40:38 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
Petro123, почему ты упорно пытаешься всю жизнь свести к одному варианту, одному маппингу и одной модели? Я пытаюсь сделать не это. Я пытаюсь доказать, что за исключением того, что во втором варианте в телефоне нет ссылки на сотрудника, варианты одинаковые. Можно/нельзя удалять, Допускать/Не допускать висячие телефоны настраивается одинаково для обоих вариантов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 14:40:40 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
javapeckerPetro123, почему ты упорно пытаешься всю жизнь свести к одному варианту, одному маппингу и одной модели? Я пытаюсь сделать не это. Я пытаюсь доказать, что за исключением того, что во втором варианте в телефоне нет ссылки на сотрудника, варианты одинаковые. Можно/нельзя удалять, Допускать/Не допускать висячие телефоны настраивается одинаково для обоих вариантов. ок. Давай свой вариант, только проверь каскад и отсутствие висячих (мне именно это надо было) Для сабжа и ТС это будет идеальный вариант. Ведь так? И закроем тему) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 14:55:11 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
Petro123, автор1. Сотрудник ---> Заказы для Организации где плевать на заказы (удалять надо) 2. Сотрудник ---> Заказы для Организации с производством Товаров (удалять нельзя, т.к. они Главные) Если у меня фигурирует заказ самостоятельно где-то , например я получаю список заказов , и для каждого заказа хочу посмотреть к какому сотруднику он относится, мне ЕСТЕСТВЕННО ПОНАДОБИТСЯ ССЫЛКА на сотрудника в заказе. Тут вопрос не в том, могут существовать сиротливые заказы или нет и кто главный, и однозначно, в обоих случаях только твой первый вариант. Второй вариант подойдет для случая когда мне не нужно из заказа тянуть сотрудника. Для заказа это маловероятная ситуация, а вот для телефона самое оно. Потому что вполне у меня может быть список сотрудников, я выберу конкретного сотрудника и посмотрю его телефоны. При этом наоборот мне не надо, то есть я не хочу получать список телефонов, открывать телефон и смотреть чей он. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 14:55:34 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
Petro123, Для сабжа и ТС это будет идеальный вариант или эмбед, если на телефоны никто кроме сотрудника не будет ссылаться ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 14:58:12 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
javapeckerPetro123, Для сабжа и ТС это будет идеальный вариант или эмбед, если на телефоны никто кроме сотрудника не будет ссылаться да. Я говорил, что редко бывает, т.к. часто ссылаются и табла разрастается до сущности. Но как пример в 1 проценте случаев - согласен. Тут ТС'ше выбирать ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 15:01:43 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
Petro123, Тут ТС'ше А с чего ты взял что ТС женского пола? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 15:27:13 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
javapecker, off ну, если она возмутится, то скажу)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 15:33:48 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
Petro123, тесты интересные: В первом варианте нужно обязательно перед сохранением установить в коменте книгу, а в книге добавить этот комент, иначе срабатывает ограничение нот нулл на фк. Потом сохраняем книгу - каскадом сохраняется и комент. Хибер делает два инсерта. Во втором варианте книге добавляем комент и сохраняем книгу. Каскадом сохраняется и комент. Хибер делает два инсерта и один апдейт комента. Так что, поведение все-таки не совсем одинаковое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 16:01:33 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
javapecker, да. много чего разного. Хотя скажу, чисто по БД, то при варианте "Справочник Городов\Адресов\Телефонов - главный" - делается внешний ключик FK и направление связи меняется. т.е. Один город в виде его Id в таблицу-класс Сотрудник. Но это вроде оффтоп. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 16:17:59 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
Petro123, согласен, а как определить кто главный если это например сотрудники и автомобили в связи один ко многим? Сотрудник содержит список авто, авто содержит ссылку на сотрудника. По условию одно авто может быть привязано только к одному сотруднику в один момент времени. а у сотрудника может быть сколько хочешь авто одновременно. Авто может вполне быть не занято, сотрудник может не иметь ни одного авто. При удалении сотрудника я не имею права удалять авто, и наоборот. Но, при удалении сотрудника, я обязан почистить ссылки на него у всех его авто. А при удалении авто я обязан удалить его из списка сотрудника, который на нем ездил. По-моему тут равноправие. Вопрос, как чистисть ссылки? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 16:33:28 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
off javapecker, начать от печки, т.к. БА вводит понятие время (твоё - "в один момент времени") Т.е. переход на классику много ко много и промежуточная таблица в виде "Документ-текущийАвтомобиль". Т.е. незанятое авто, у которого просрочен или снята галка в Документе выше. Ссылки чистить процедурами Бизнес-слоя "ЗаключитьКонтракт" \ АннулироватьКонтракт. При аннулировании можешь стереть запись или отправить в архив или (спроси у БА) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 16:50:51 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
Petro123Нафига иметь телефонный номер в БД без сотрудника? Т.е. ничей?Да. А почему это так удивляет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2012, 06:34:52 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
Так а по существу вопроса? Есть мэппинг двух сущностей Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. То есть я не хочу, чтобы из Comment был доступ к его соотв Book. Поэтому у меня нет в классе Comment - setBook()/getBook(). В данном случае будет же тот же самый результат, как если бы я убрал Код: java 1. 2. из класса Comment. Разве нет? Но просто ж не будет создаваться дополнительная промежуточная таблица. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2012, 00:43:23 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
Сорри, ошибка Правильно Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2012, 00:47:33 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
oson, по существу вам был дан рабочий код. Хибер и маппинг подстраивается под РСУБД, а не наоборот. Поэтому будьте добры включите генерацию БД хибером и протестируйте свой код (классы -- маппинг --DDL --main{}) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2012, 01:35:23 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
oson, По существу мы чуть не подрались из-за вашего вопроса. А вы опять все перепутали. Давайте по порядку. Ваш вопрос был о том, как лучше замапить книги и коменты так, чтобы коменты о книгах не знали, и доп. таблицу хибер не создал. Рассмотрим ваш вариант из последнего поста. Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. Еще раз напомню, что значит mappedBy. Это указание хиберу, что там где стоит мапед бай, свзяь мапить не надо, что эта связь уже замаплена на другом конце связи. В вашем случае не стороне комента уже стоит @ManyToOne. А теперь подумайте. Если связь замаплена со стороны комента, то и задавать ее надо со стороны комента. А вы убрали геттеры и сеттеры оттуда. Как теперь вы зададите, к какой книге относится комент? Петро был прав, когда посоветовал вам сделать маленькие проекты и потестить их, тогда все сразу станет видно. Таким образом, остаются два варианта: 1. Использовать связь только со стороны книги: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 2. Если у вас не будет больше в модели никаких сущностей, которые будут ссылаться на коменты (кроме книг), вы можете представить коменты как коллекцию компонентов класса книги. Мапится так: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. В таком случае, ответственность за коменты полностью лежит на книге. Нельзя сохранить сиротливый комент, при удалении книги все коменты удаляются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2012, 14:10:10 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=38021657&tid=2130646]: |
0ms |
get settings: |
15ms |
get forum list: |
21ms |
check forum access: |
6ms |
check topic access: |
6ms |
track hit: |
51ms |
get topic data: |
17ms |
get forum data: |
4ms |
get page messages: |
88ms |
get tp. blocked users: |
3ms |
| others: | 348ms |
| total: | 559ms |

| 0 / 0 |
