我认为是时候看看 OO 数据库了，并决定将 db4o 用于我的下一个小项目 - 一个小型库。
考虑以下对象:Book、Category。
一本书可以属于 0-n 个类别，而一个类别可以应用于 0-m 本书。
我的第一个想法是拥有一个连接对象，例如 BookCatecory，但经过一番谷歌搜索后，我发现这不适合“真正的 OO”。
所以另一种方法(许多人推荐)是在两个对象中都有一个列表:Book.categories 和 Category.books。一方面处理关系:Book.addCategory 将 Category 添加到 Book.categories 和 Book 到 Category.books。在一个方法调用中更改 2 个对象时，如何处理提交和回滚？
你怎么看？第二种方法有明显的优势，但至少对我来说，第一种“感觉”是正确的(更好的规范)。
最佳答案
我真的只有两种方法可以解决这个问题，你已经提到了这两种方法。就个人而言，我会采用第一种方法(将映射对象创建为 OO 实体)。这可以防止您保留冗余信息而不必同步；这也意味着，如果关联最终拥有自己的字段(比方说将图书分配到该类别的日期)，则可以轻松合并它们。我们将这种方法用于我们系统中的各种关联。
OO 实体看起来像:
BookCategory {
Book book
Category category
}
Book {
Collection <BookCategory> categories
}
Category {
Collection <BookCategory> categories
}
在这里你必须保持关系对象和两个集契约(Contract)步；但是，在这种情况下，集合是可选的。通常，您可以使用 ORM 查询获得相同的信息，例如:
从 BookCategory b 中选择 b.book，其中 b.category = MyCategory
另一种方法是进行如下设置:
Book {
Collection<Category> categories
}
Category {
Collection<Books> books
}
如果您的 ORM/DB 工具自动维护关联，这很好；否则，您将无法更新两个集合。 (在 Hibernate 中，映射的一侧将具有属性:inverse=true；这一侧没有更新，所以严格来说它不需要维护。不过，这在我看来是不好的做法。)
如果您通常只以一种方式访问关系(例如，获取类别中的所有书籍)，则可以消除另一侧的集合；那么我认为您必须绕过 ORM 工具并使用 native 查询才能从另一个方向访问关系。
我们在我们的项目中使用 Hibernate(一种基于 Java 的对象关系映射工具)； Hibernate 文档是 OO/关系设计问题的一个很好的引用，尽管您可能需要花一点时间学习 Hibernate 才能使它们有用:
http://docs.jboss.org/hibernate/stable/core/reference/en/html_single/#collections-ofvalues
哼!
关于oop - 如何在对象数据库中设计多对多关系？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1069187/