powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Java [игнор отключен] [закрыт для гостей] / Мэппинг для однонаправленной связи
23 сообщений из 48, страница 2 из 2
Мэппинг для однонаправленной связи
    #38021657
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
javapeckerНе понимаю почему вдруг таблица телефонов стала главной.
если в ТЗ вместо Телефона - Адрес, то БА может задать требования и делаем Модель по варианту 2
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021719
javapecker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123,
Я спрашиваю, почему в своем варианте ты называешь главной таблицу сотрудников, а во втором варианте главной - таблицу телефонов? База одинаковая в одном и другом случае. В приложении разница только в том, что в телефоне нет ссылки на сотрудника. В коде который ты выложил нет никаких ограничений, которые запретили бы создавать висячий телефон. В моем варианте их тоже нет, но если сделать так в твоем:
Код: java
1.
2.
    @ManyToOne(optional=false)
    private Book book;


или так в моем:
Код: java
1.
2.
3.
 @OneToMany(cascade= CascadeType.ALL)
    @JoinColumn(name = "book_id",nullable=false)
    private List<Comment> clist = new ArrayList<>();


то ты не сможешь сохранять сиротливые телефоны и там и там. И все.
по поводу этого:
Нафига иметь телефонный номер в БД без сотрудника? Т.е. ничей?
См. выше - установи ограничения. Есть они или нет - они одинаково работают для первого и второго варианта. Ну и кстати, а нафига мне иметь в телефонном номере ссылку на сотрудника? я нигде не буду пользоваться номером отдельно от сотрудника. И у меня навигация будет всегда от сотрудника к телефону, но не наоборот. Поэтому - второй вариант. И в твоем и в моем варианте связью нужно управлять, эмбед позволяет это делать автоматически без использования каскада. Поэтому еще лучше - третий вариант, потому что он гарантирует, что сиротливых телефонов не будет и они всегда будут синхронизированы с сотрудником.
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021762
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
javapecker,
не понятно, почему ты упорно пытаешься всю жизнь свести к одному варианту, одному маппингу и одной модели?

Возьми Access и посмотри.
Один ко многим:
1. Сотрудник ---> Заказы для Организации где плевать на заказы (удалять надо)
2. Сотрудник ---> Заказы для Организации с производством Товаров (удалять нельзя, т.к. они Главные)

Будет 2 модели по Бизнесу, а также разный ГУИ!
ОК?

PS/ Каскад решает очень многое.
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021771
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
javapecker,
давай, сделай примерчики, и завтра поковыряем демки и генерацию схемы хибером.
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021784
javapecker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123, сделал под нетбинс 7.2+Postgres. В первых двух случаях схема генерится одинаковая. Висячие телефоны сохраняются. С добавлением optional = false или nullable = false не сохраняются. В третьем случае для телефона генерится таблица без первичного ключа с фк на сотрудника. Выложить проекты?
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021789
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
javapeckerНу и кстати, а нафига мне иметь в телефонном номере ссылку на сотрудника?
afaik на rsdn чел мучился именно с каскадом.
У него не выходило именно без этой ссылки.
Попробуй и выложи минимальный с каскадом для 1-го варианта.
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021793
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
javapecker,
проекты не надо. Лучше как выше написал:
1. Каскад без висячих
2. без каскада + висячие само собой
3. без PK
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021794
javapecker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123,
почему ты упорно пытаешься всю жизнь свести к одному варианту, одному маппингу и одной модели? Я пытаюсь сделать не это. Я пытаюсь доказать, что за исключением того, что во втором варианте в телефоне нет ссылки на сотрудника, варианты одинаковые. Можно/нельзя удалять, Допускать/Не допускать висячие телефоны настраивается одинаково для обоих вариантов.
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021833
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
javapeckerPetro123,
почему ты упорно пытаешься всю жизнь свести к одному варианту, одному маппингу и одной модели? Я пытаюсь сделать не это. Я пытаюсь доказать, что за исключением того, что во втором варианте в телефоне нет ссылки на сотрудника, варианты одинаковые. Можно/нельзя удалять, Допускать/Не допускать висячие телефоны настраивается одинаково для обоих вариантов.
ок.
Давай свой вариант, только проверь каскад и отсутствие висячих (мне именно это надо было)
Для сабжа и ТС это будет идеальный вариант. Ведь так?
И закроем тему)
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021834
javapecker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123,

автор1. Сотрудник ---> Заказы для Организации где плевать на заказы (удалять надо)
2. Сотрудник ---> Заказы для Организации с производством Товаров (удалять нельзя, т.к. они Главные)


Если у меня фигурирует заказ самостоятельно где-то , например я получаю список заказов , и для каждого заказа хочу посмотреть к какому сотруднику он относится, мне ЕСТЕСТВЕННО ПОНАДОБИТСЯ ССЫЛКА на сотрудника в заказе. Тут вопрос не в том, могут существовать сиротливые заказы или нет и кто главный, и однозначно, в обоих случаях только твой первый вариант. Второй вариант подойдет для случая когда мне не нужно из заказа тянуть сотрудника. Для заказа это маловероятная ситуация, а вот для телефона самое оно. Потому что вполне у меня может быть список сотрудников, я выберу конкретного сотрудника и посмотрю его телефоны. При этом наоборот мне не надо, то есть я не хочу получать список телефонов, открывать телефон и смотреть чей он.
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021836
javapecker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123,
Для сабжа и ТС это будет идеальный вариант
или эмбед, если на телефоны никто кроме сотрудника не будет ссылаться
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021844
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
javapeckerPetro123,
Для сабжа и ТС это будет идеальный вариант
или эмбед, если на телефоны никто кроме сотрудника не будет ссылаться
да. Я говорил, что редко бывает, т.к. часто ссылаются и табла разрастается до сущности.
Но как пример в 1 проценте случаев - согласен. Тут ТС'ше выбирать )))
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021926
javapecker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123,
Тут ТС'ше
А с чего ты взял что ТС женского пола?
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021940
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
javapecker,
off
ну, если она возмутится, то скажу))
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38022001
javapecker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123,
тесты интересные:

В первом варианте нужно обязательно перед сохранением установить в коменте книгу, а в книге добавить этот комент, иначе срабатывает ограничение нот нулл на фк. Потом сохраняем книгу - каскадом сохраняется и комент. Хибер делает два инсерта.

Во втором варианте книге добавляем комент и сохраняем книгу. Каскадом сохраняется и комент. Хибер делает два инсерта и один апдейт комента.
Так что, поведение все-таки не совсем одинаковое.
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38022049
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
javapecker,
да.
много чего разного.
Хотя скажу, чисто по БД, то при варианте "Справочник Городов\Адресов\Телефонов - главный" - делается внешний ключик FK и направление связи меняется.
т.е.
Один город в виде его Id в таблицу-класс Сотрудник.
Но это вроде оффтоп.
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38022085
javapecker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123,
согласен, а как определить кто главный если это например сотрудники и автомобили в связи один ко многим? Сотрудник содержит список авто, авто содержит ссылку на сотрудника. По условию одно авто может быть привязано только к одному сотруднику в один момент времени. а у сотрудника может быть сколько хочешь авто одновременно. Авто может вполне быть не занято, сотрудник может не иметь ни одного авто. При удалении сотрудника я не имею права удалять авто, и наоборот. Но, при удалении сотрудника, я обязан почистить ссылки на него у всех его авто. А при удалении авто я обязан удалить его из списка сотрудника, который на нем ездил. По-моему тут равноправие. Вопрос, как чистисть ссылки?
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38022129
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
off
javapecker,
начать от печки, т.к. БА вводит понятие время (твоё - "в один момент времени")
Т.е. переход на классику много ко много и промежуточная таблица в виде "Документ-текущийАвтомобиль".
Т.е. незанятое авто, у которого просрочен или снята галка в Документе выше.

Ссылки чистить процедурами Бизнес-слоя "ЗаключитьКонтракт" \ АннулироватьКонтракт.
При аннулировании можешь стереть запись или отправить в архив или (спроси у БА)
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38022685
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123Нафига иметь телефонный номер в БД без сотрудника? Т.е. ничей?Да.
А почему это так удивляет?
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38024194
Фотография oson
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Так а по существу вопроса?


Есть мэппинг двух сущностей

Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
@Entity
@Table(name = "COMMENTS")
public class Comments
{
    @ManyToOne
    @JoinColumn(name = "BOOK_ID")
    private Book book;
}


@Entity
@Table(name = "BOOKS")
public class Comment
{
    @OneToMany(mappedBy = "book")
    private List<Comment> comments;

    public List<Comment> getComments() {}
    public void setComments(List<Comment>) {}
}



То есть я не хочу, чтобы из Comment был доступ к его соотв Book.
Поэтому у меня нет в классе Comment - setBook()/getBook().
В данном случае будет же тот же самый результат, как если бы я убрал

Код: java
1.
2.
 @ManyToOne
    @JoinColumn(name = "BOOK_ID")



из класса Comment. Разве нет?
Но просто ж не будет создаваться дополнительная промежуточная таблица.
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38024199
Фотография oson
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сорри, ошибка
Правильно

Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
@Entity
@Table(name = "COMMENTS")
public class Comments
{
    @ManyToOne
    @JoinColumn(name = "BOOK_ID")
    private Book book;
}


@Entity
@Table(name = "BOOKS")
public class Book
{
    @OneToMany(mappedBy = "book")
    private List<Comment> comments;

    public List<Comment> getComments() {}
    public void setComments(List<Comment>) {}
}
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38024233
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
oson,
по существу вам был дан рабочий код.
Хибер и маппинг подстраивается под РСУБД, а не наоборот.
Поэтому будьте добры включите генерацию БД хибером и протестируйте свой код (классы -- маппинг --DDL --main{})
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38024422
javapecker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
oson, По существу мы чуть не подрались из-за вашего вопроса. А вы опять все перепутали. Давайте по порядку. Ваш вопрос был о том, как лучше замапить книги и коменты так, чтобы коменты о книгах не знали, и доп. таблицу хибер не создал. Рассмотрим ваш вариант из последнего поста.
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
@Entity
@Table(name = "COMMENTS")
public class Comments
{
    @ManyToOne
    @JoinColumn(name = "BOOK_ID")
    private Book book;
}


@Entity
@Table(name = "BOOKS")
public class Book
{
    @OneToMany(mappedBy = "book")
    private List<Comment> comments;

    public List<Comment> getComments() {}
    public void setComments(List<Comment>) {}
}



Еще раз напомню, что значит 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.
@Entity
@Table(name = "COMMENTS")
public class Comments
{
    //здесь вообще не задана связь с книгой, комент ничего про книгу не знает
    String comment;
    
}


@Entity
@Table(name = "BOOKS")
public class Book
{
    @OneToMany()//вся связь замаплена в этом классе
    @JoinColumn(name = "BOOK_ID",nullable = false)    
    private List<Comment> comments;

    public List<Comment> getComments() {}
    public void setComments(List<Comment>) {}
}


2. Если у вас не будет больше в модели никаких сущностей, которые будут ссылаться на коменты (кроме книг), вы можете представить коменты как коллекцию компонентов класса книги. Мапится так:
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
@Embeddable
@Table(name = "COMMENTS")
public class Comments
{
    //здесь вообще не задана связь с книгой, комент ничего про книгу не знает
//если не предпринимать специальные меры
    String comment;
    
}


@Entity
@Table(name = "BOOKS")
public class Book
{
    @ElementCollection //для 4-го хибера, в третьем вроде  @CollectionOfElements
    private List<Comment> comments;

    public List<Comment> getComments() {}
    public void setComments(List<Comment>) {}
}


В таком случае, ответственность за коменты полностью лежит на книге. Нельзя сохранить сиротливый комент, при удалении книги все коменты удаляются.
...
Рейтинг: 0 / 0
23 сообщений из 48, страница 2 из 2
Форумы / Java [игнор отключен] [закрыт для гостей] / Мэппинг для однонаправленной связи
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]