В реляционном программировании существует отношение "многие ко многим" и стандартный способ его реализации — таблица с колонками, идентифицирующими сущности, между которыми такое отношение устанавливается:

Entity1
(
  id,
  ...
)

Entity2
(
  id,
  ...
)

Entity1_2_Entity2
(
  entity1_id,
  entity2_id
)

Хотелось бы узнать, какие подходы к реализации таких отнощений существуют в ООП, в чём их недостатки и преимущества. Заранее спасибо.

Здравствуйте, Аноним, Вы писали:

А>В реляционном программировании существует отношение "многие ко многим" и стандартный способ его реализации — таблица с колонками, идентифицирующими сущности, между которыми такое отношение устанавливается:

А>

А>Entity1
А>(
А>  id,
А>  ...
А>)

А>Entity2
А>(
А>  id,
А>  ...
А>)

А>Entity1_2_Entity2
А>(
А>  entity1_id,
А>  entity2_id
А>)
А>

А>Хотелось бы узнать, какие подходы к реализации таких отнощений существуют в ООП, в чём их недостатки и преимущества. Заранее спасибо.


В ООП можно реализовать целый букет подходов к представлению такого отношения.

Во-первых можно определить класс-отношение c атрибутом-коллекцией ссылок на объекты, связанные отношением.
Во-вторых можно в состав самих объектов-участников ввести ссылки (коллекции ссылок) на объекты-отношения.
В-третьих можно полностью сдублировать представленную выше реляционную структуру, определив класс Entity1_2_Entity2 с атрибутами ссылками ent1, ent2 (очень плохой вариант, поскольку в этом случае для получения информации о любом отношении прийдется перебирать все элементы класса)
В-четвертых, можно рассматривать отношение многие-ко-многим как объект-коллекцию отношений 1-1.

В конечном счете все определяется потребностями и логикой конкретного приложения.

Здравствуйте, Alexey Rovdo, Вы писали:


AR>В ООП можно реализовать целый букет подходов к представлению такого отношения.

AR>Во-первых можно определить класс-отношение c атрибутом-коллекцией ссылок на объекты, связанные отношением.
Это, как я понимаю,

class Relation
{
Collection Entities1;
Collection Entities2;
}

и потом, для проверки наличия отношения между e1 и e2 надо убедиться в наличии обоих в соотв. коллекции, так?

AR>Во-вторых можно в состав самих объектов-участников ввести ссылки (коллекции ссылок) на объекты-отношения.

class Entity1
{
Collection Entities2;
}

AR>В-третьих можно полностью сдублировать представленную выше реляционную структуру, определив класс Entity1_2_Entity2 с атрибутами ссылками ent1, ent2 (очень плохой вариант, поскольку в этом случае для получения информации о любом отношении прийдется перебирать все элементы класса)
Ага, именно это я делать очень не хотел, потому и возник вопрос.

AR>В-четвертых, можно рассматривать отношение многие-ко-многим как объект-коллекцию отношений 1-1.
class one2one
{
Entity1 e1;
Entity2 e2;
}

class Relation
{
Collection one2onecollection;
}
так чтоли? а чем это принципиально от предыдущего способа отличается? Или я чего то не понимаю?

AR>В конечном счете все определяется потребностями и логикой конкретного приложения.
Тут вся штука в том, что некоторые из этих отношений у меня имеют дополнительные параметры, описывающие эти отношения или поведение объектов, в них учавствующих. Тоесть, в структуре бд эти отношения являются таки объектами. Некрасивый вариант выглядит подходящим. Никак не могу выбрать законченное решение... Надеюсь, конструктивный диалог с коллегами поможет...

Хочу немного уточнить свой вопрос .. В ветке выше мне предоставили несколько вариантов. Все они позволяют довольно просто получить ответ на вопрос "Связяны ли между собой А и Б?", но есть другие, на которые мне нужно быстро получать ответы:
1. Найти все Entity2, привязанные к конкретной Entity1.
2. Обратное к (1).

Здравствуйте, Аноним, Вы писали:

Наиболее частое решение этой проблемы — реализация списков ссылок на соседний объект.

Entity1
(
  Entity2[] ent2,
  ...
)
Entity2
(
  Entity1[] ent1,
  ...
)

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

С уважением, Gleb.