Как разработать many-many отношения в объектной базе данных?

Я думаю, вы просто немного зациклились на реляционном образе мышления БД. Списки в каждом объекте - это правильный объектно-ориентированный подход. Коммиты и откаты - не проблема, они происходят в транзакции, которая фиксирует все или все откатывает.

В чистой объектно-ориентированной базе данных, такой как GemStone, сами объекты имеют коллекции ссылок на другие объекты. Когда на объект ссылается приложение, OODBMS генерирует прокси-сервер, который обертывает объект. Схема для этого - просто постоянный объект и его коллекция ссылок на объекты, на которые он ссылается. OODBMS не обязательно нуждается в связующем объекте.

С уровнем отображения O / R (при условии, что он достаточно умен, чтобы устанавливать отношения M: M), отношение M: M проявляется как совокупность вспомогательных ссылок на сам объект который преобразователь O / R разрешает в сущность ссылки за кулисами. Не все преобразователи O / R делают это, поэтому у вас может быть отдельный объект ссылки.

У вас есть какая-то конкретная причина, по которой вы хотели бы использовать ODBMS? Для простых структур данных (таких как категоризация книг) вы, как правило, не найдете никаких преимуществ в ODBMS по сравнению с RDBMS, и на самом деле вам будет легче работать в гораздо более стандартизированном мире RDBMS. ODBMS имеет очень ощутимые преимущества, когда вы работаете со сложными типами данных или буквальным постоянством / хранением динамических объектов. ODBMS также считается намного более быстрой и масштабируемой, чем RDBMS, хотя я сам мало что могу в этом сказать. Вот пара страниц, на которых обсуждаются РСУБД и ODBMS:

Что бы ни случилось с объектно-ориентированными базами данных

Объектно-ориентированная база данных против объектно-реляционной базы данных (SO)

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

Уловка здесь - ссылки.

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

Таблица соответствия является реляционной концепцией, если только этот промежуточный соединительный класс не может иметь свойства, не относящиеся ни к одному из объекты. Он существует, поскольку позволяет писать запросы мощным способом, поскольку сокращает отношение до двух отношений один ко многим и значительно сокращает дублирование данных. Если бы вы сделали это в базе данных отношений без таблицы сопоставления, то все очень быстро испортилось бы - как будет работать обновление? Лично я нахожу привлекательность oo-баз данных в том, чтобы отойти от этого

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

На самом деле я могу придумать только два способа решения этой проблемы, оба из которых вы упомянули. Лично я бы выбрал первый подход (создание объекта отображения как объектно-ориентированного объекта). Это предотвращает хранение избыточной информации и необходимость синхронизации; это также означает, что если ассоциация в конечном итоге имеет собственные поля (скажем, дату, когда книга была отнесена к этой категории), их можно легко включить. Мы используем этот подход для множества ассоциаций в нашей системе.

Объектно-ориентированные объекты будут выглядеть так:

BookCategory {
 Book book
 Category category
}
Book {
 Collection <BookCategory> categories
}
Category {
 Collection <BookCategory> categories
}

Здесь вы должны синхронизировать объект отношения и две коллекции; однако в этом случае коллекции необязательны. Обычно вы можете получить ту же информацию с помощью запроса ORM, например: выберите b.book из BookCategory b, где b.category = MyCategory

Альтернативой является настройка, например:

Book {
 Collection<Category> categories
}

Category {
 Collection<Books> books
}

Если ваш инструмент ORM / DB автоматически поддерживает ассоциации, это нормально; в противном случае вы застряли при обновлении обеих коллекций. (В Hibernate одна сторона будет иметь свойство: inverse = true в сопоставлении; эта сторона не обновляется, поэтому, строго говоря, ее не нужно поддерживать. Однако это кажется мне плохой практикой.)

Если вы обычно получаете доступ к отношению только одним способом (например, получаете все книги в категории), вы можете удалить коллекцию с другой стороны; тогда я думаю, вам придется обойти инструмент ORM и использовать собственный запрос, чтобы получить доступ к взаимосвязи с другого направления.

Мы используем Hibernate (инструмент объектно-реляционного сопоставления на основе Java) в нашем проекте; http://docs.jboss.org/hibernate/stable/core/reference/en/html_single/#collections-ofvalues ​​

HTH!