在关系结构中，一对多是最常见也是最简单的关系。一般需要两个管理界面(interface)进行管理:主记录的管理，基于主记录对子记录的管理界面。而
对于一个多对多关系在应用客户端，一般需要三到四个管理界面进行管理：主表记录的添加和管理界面，基表记录的添加和管理界面，以及以主表为基准对关系记录
（多对多的关联表）的管理界面，有可能还包括以基表记录为基准的对多对多关系的管理界面。每一个一般情况下都不算太复杂，但当记录达到成千上万时，每一个
这样的一个实体结构的管理都成为名符其实的大工程，并且，很难复制；当遇到新的模块实体时，只能按同样的方式再次开发，而极难达到重用的水平。
对象数据库完全抛弃了多对多，甚至是一对多的关系结构，采用子集合的形式，作为对象的一个属性存在。但对于多对多形式，仍然存在一个基类确定的困难：没有
了多表关系，意味着常规的设立基表的办法不再通用于对象数据范式。象PMI(Privileges Management
Infrastruture，权限管理基本架构)中的RBAC(Role Based Access Control，组角色管理），就算可以把组作为人员对象属性，但总还需要有一个地方定义组和访问对象吧？结果，必然导致另一个象组对象这样的基对象的产生，同时出现另一个问题，就是两个对象各自管理同类属性时出现的一致性冲突的可能。
如果仅仅是在两层应用系统中，由于应用端可以直接调用sql，所以这时侯考虑对象存储范式反而显得复杂低效；但在基于关系对象映射（OR）的三层结构应用
中，复杂的多对多关系无论是使用BMP还是CMP配置，都是复杂而多歧义的，这时侯，很自然就会产生是否能够通过把关系结构异化成对象结构实现单表存储
（形式上），从而简化了OR的难度并提高了它的可用性呢？这样，对象范式的数据库就有了存在的积极意义。
但是在OR映射中，对象的集合属性和一般属性还是有着很大的区别的。最起码，它很难使用简单的setter/getter进行设置和访问；这就已经超出了
目前java有关现行规范的范围。而且，很重要的是，这种集合如果按照sql92的标准组织的话，通常是需要进一步的初始化才能从普通形式的属性转为对象
的集合属性，除非，使用特定数据库的特定属性，象OC4j中使用oracle中的行集合；从通用性来说，这种解决方案过分基于某一单一厂商，那怕是
oracle或者微软这样的大公司，都是令人难以接受的；特别是对于java这样与平台无关的解决方案，却要与某个数据库方案绑定，简直就是笑话。
另一方面，这种初始化对象集合属性的操作也不应该由对象的消费者来调用，对于调用者来说，对象属性的无论原始组织就是集合，还是是从普通属性转化来的，都
应该是透明的，无非考虑的，否则就失去了OR映射的意义。这个初始化过程，毫无疑问应该是在find得到这个对象之前的过程中完成。对于对象管理容器来
说，在获得对象基本属性后针对对象的另一个设置实行进一步的初始化，并不是一件困难的事情。
这样，对于使用者来说，对象的复杂关系就可以隐藏着简单的getByName这样的方法下面，通过简单的add/remove方法进行管理，或者通过iterate实现穷举迭代；总之，可以减少了对多对多结构模型的开发难度。这样，OR才是用得其所。
包括J2EE，Hibernate,Liberante,JDO，HanvaJDO在内的诸多OR对象映射方案，是继续采用面向传统的关系映射方式，艰难
地与多对多关系的布署困难作斗争，还是改改思路，针对对象来存储已有数据，大概会是一个值得思索的问题。这个问题换一种说法也就是：对象（应用）方式与关
系（存储）方式，总有一个向另一个妥协，今天是对象应用向关系存储范式妥协，反过来，如果让关系结构向对象应用范式妥协，是否会打开一遍新的天地呢？
