использовать один-ко-многим или многие-к-одному

Question

Два класса:

Задача отдела

В одном отделе может быть много задач. Одна задача может принадлежать только одному отделу.

Так использовать один-ко-многим или многие-к-одному?

---

one-to-many
class Department{
  private Set tasks;
}
class Task{
  ......
}
//
Department.hbm.xml
....
<set name="tasks">
    <key column="departId" />
    <one-to-many class="Task" />
</set>
.....

---

многие к один

class Department{

}
class Task{
  Department depart;
}
//
Task.hbm.xml
....
<property name="depart">
    <many-to-one class="Department" />
</property>
.....

---

Какая разница?

Кстати, в чем разница между использованием набора и списка?

А пример использования списка (конфигурация xml)?

Answer 1

Задача не может существовать без отдела, я полагаю, но отдел может существовать без связанной с ним задачи.Таким образом, зависимость заключается в Задаче присоединиться к Департаменту, следовательно, должна быть сторона-владелец в отношениях.Многие-к-одному должны быть вашим выбором здесь.

Answer 2

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

Из коллекций Java набор не допускает дублирование, тогда как список может

Answer 3

Ваш выбор будет зависеть от 2 вещей:

1. Каковы различные сценарии, в которых используются эти отношения.Например, если вам нужно перечислить свои задачи по отделам, то вам понадобится One to Many.Вам также будет легко загрузить их один раз, так как вы используете Hibernate.

2. Если вы обновляете свои задачи по отделам, тогда вам нужны и другие отношения.

Однако помните, что эти решения имеют глубокие корни в вашей областимодель и как вы хотите ее структурировать.Каковы варианты использования, под которыми эти объекты используются.Я настоятельно рекомендую прочитать эту SO ветку и более того посмотреть это видео Эрика Эванса .

Надеюсь, что это поможет.

Answer 4

Вы должны определить таблицу соединения с именем DEPARTMENT_TASKS и иметь между собой отношение ManyToMany.