我想应该是时候看看OO数据库，并决定使用db4o的我的下一个小项目 - 一个小型图书馆。
考虑以下对象：图书，类别。
一本书可以是0-n的种类和类别可以应用到0-m的图书。
我首先想到的是有一个连接对象，如BookCatecory但有点谷歌搜索我看到，这是不恰当的“真正的'00”后。
因此，另一种方法（由许多推荐）就是在两个对象的列表：Book.categories和Category.books。 一边处理关系：Book.addCategory增加了类别，以Book.categories并预订到Category.books。 如何处理提交和回滚时，2个物体被一个方法调用内改变？
你的想法是什么？ 第二种方法具有明显的优势，但是，至少对我来说，第一个“感觉”的权利（更好范）。
如果你使用对象数据库，你不需要关心的关系如何存储在数据库中。 您定义它们之间的类和关系。 请阅读引导到你的数据库中的参考。 关系的例子：
n:n attribute, referencing from the parent
------------------------------------------------------------------
class Person{
List addresses;
}
class Address{
}
n:n attribute, referencing from the child
------------------------------------------------------------------
class Person{
}
class Address{
List persons
}
n:n attribute, bidirectional references
------------------------------------------------------------------
class Person{
List addresses;
}
class Address{
List persons
}
其实只有两种方式我能想到的解决这个问题，这两者你所提到的。 就个人而言，我会去与第一种方法（创建一个映射对象作为OO实体）。 这可以防止周围保持冗余信息，需要同步; 这也意味着，如果关联结束有其自身的领域（这本书被分配到该类别的日期，让我们说），他们可以很容易地合并。 我们使用这种方法适用于各种在我们的系统关联。
二OO实体将如下所示：
BookCategory {
Book book
Category category
}
Book {
Collection <BookCategory> categories
}
Category {
Collection <BookCategory> categories
}
在这里，你必须保持关系对象和同步的两个集合; 然而，集合在这种情况下，可选的。 通常，你可以得到与ORM查询相同的信息，是这样的：从BookCategory选择b.book b，其中b.category = MyCategory
另一种方法是有一个像设置：
Book {
Collection<Category> categories
}
Category {
Collection<Books> books
}
如果你的ORM / DB工具自动维护的关联，这是好的; 否则，你被卡住更新两个集合。 （在Hibernate中，一面将有属性：逆=上映射真实的;不更新这一边，所以严格来说，它并不需要维持这似乎对我来说，坏的做法，虽然）。
如果您通常只访问关系的一种方式（例如，让所有的在一个类别的书籍），可以消除对方的集合; 那么我认为你将不得不解决的ORM工具，以从另一个方向进入的关系，使用本机查询。
我们在我们的项目中使用Hibernate（一个基于Java的对象关系映射工具）; Hibernate的文档是面向对象/关系设计问题的一个很好的参考，虽然你可能要花费一点时间来学习Hibernate来使它们非常有用： http://docs.jboss.org/hibernate/stable/core/reference/en/ html_single /＃集合，ofvalues
HTH！
我想，你只是一个小挂了思维的关系数据库的方式。 每个对象列表是正确的面向对象的事情。 提交和回滚都没有问题，但在这一切提交或回滚一切事务发生。
在纯面向对象的数据库，如GemStone的对象本身对其他对象的引用的集合。 当对象从应用程序所引用的OODBMS生成一个包装对象的代理。 此架构仅仅是持久化对象，其收藏的对象引用它指的是。 在面向对象数据库系统并不一定需要一个链接实体。
用O / R映射层（假设它是足够聪明做L：m关系）所述M：M关系表现为其中O / R映射器解析为后面的链接实体对象本身上附属引用的集合场景。 并非所有的O / R映射器做到这一点，所以你可能有一个单独的链接对象。
你有你想使用一个ODBMS什么特别的原因？ 对于简单的数据结构（如书籍分类），你一般不会找到任何ODBMS优势RDBMS，实际上将有一个更容易的时间在RDBMS的多，更标准化的世界而努力。 ODBMS具有非常实际的优势，当你有复杂数据类型或动态对象的字面持久性/存储工作。 ODBMS也被引为是更快，比RDBMS更具可扩展性，不过我可以提供一点洞察这个自己。 这里有但是，这种讨论RDBMS与ODBMS，一对夫妇的网页：
无论发生在面向对象数据库
面向对象的数据库与对象Rleational数据库（SO）
我会避免数据重复，因为你遇到的各种与合并的差异问题。
诀窍这是引用。
其结果是，我将不得不每个对象包含对其他对象类型引用的集合，以及具有其它对象的一个独立的集合。
匹配表是一个关系的概念，除非该中介连接类可能具有不是归因于任一对象的属性。 正是在那里，因为它能够在一个强大的方式来编写查询，因为它减少了相对于2一对多的关系，极大地降低了数据重复。 如果你这样做是在关系数据库不匹配表，然后事情会得到邪恶很快 - 怎么会更新操作？ 我个人认为OO数据库的吸引力，从这个踩着走
我将配合所有对象一起的方式是通过在代码中的事件某种交易处理，使物体状态的缓存。 所以，而不是对象操纵每其他性质，因为它们要求通过该处理程序的变化并等待结果在回调。
