首先说明一点，就是复杂性，在复杂性上，我一般习惯分为实现复杂性和思维复杂性，有的问题我们可以很容易的想到解，但是并不意味他是容易实现的，比如递归下降的词法分析(以及大多数递归求解算法)，具有极强的思维简洁性，但是往往具有难以想象的实现复杂度。同样，我们还有两种就是对人简单和对机器简单，对机器简单的必要条件就是可形式化为递归能行求解过程(依据图灵机原理)。ok，从这样两个复杂纬度我们来分析一下oo和er在 数据表述(请注意，我仅仅说的是数据表述，也就是一个系统的静态纬度)上的复杂度。
关系模型: 关系模型的数据模型是集合以及在集合基础上发展出来的关系。操作语义是关系运算。那么很显然对于一个有数学（离散，集合论）基础的人而言，关系模型具有思维简洁性。对于计算机而言，关系运算在有限集上是递归能行的，所以对于计算机而言，关系模型具有计算简洁性。
对象模型: 对象模型的数据模型，非常抱歉，虽然本人从94年起就开始接触OOA&D以及做相关的工作，也算个狂热的OO分子，但我不得不说，从计算机科学的角度来说，OO的数据模型未定义！但是往往大家都同意一个观点，就是用networked model或者graph model可以很好的描述oo的数据模型，因此为了讨论的方便，我们可以不严格的认为OO的数据模型是Graph Model。那么再看一下OO数据模型的操作语义，显然可以推出为图操作(基于路径)。那么我想请问一下，你在思考一个模型的时候，是集合简洁还是Graph简洁？我敢说这样的话，国内做计算机的，至少90%对图论是懵懂的，当然我也是（在下十岁起学习算法设计参加NOI/IOI竞赛的，当时主要的算法设计就是图算法，最好名次北京市第六名，也曾深入学习过离散和图论，不过仍然懵懂）更不要说用使用图来思考对象语义了。当然，这个结论有违常识，因为你会认为
Person p；
p.getName();
是很简洁的也是很好理解的，那么如你所说“请不要拿一个人能完成的小系统来作例子”，那么我们来说一下，复杂的对象系统，你怎么判定一个系统是好的？我想你会列出很多依据，不过我猜那些结论多是经验性的。对吧？比如bad smell。
那么你可曾考虑过使用图模型分析很多对象间复杂关系的设计合理性？你可曾考虑过在domain model里，使用pattern之后图模型路径的变化？你可曾想过使用图模型来改善对象的静态设计？
如果你考虑过，你就会有这样的经验，OO在数据模型设计上不具有思维简洁性。因为我们不能follow一套递归过程，之后证明我们的设计就是合理的！！！而关系模型可以，就是范式。依据范式简化，我们可以说我的关系设计是无冗余的，是如何的，但是对象模型你就无能为力了。
我可以以我的经验告诉你，对象模型的优劣和一个对象图上的生成树，环的个数以及通度有关。但是具体关系，sorry，然后是未知的。我马上要在oo上进行的一个研究，就是分析各种OOA&D流派对对象图的改变，以及在图中引入的边语义。哎这个说的有点跑题。
我们会过来看OO的计算机处理，非常不幸，在包含环的Graph Model上的运算，虽然是递归可解的，但是费用相当的高。因此可以说OO不具有计算简洁性。
那么OO不具有思维简洁性不具有计算简洁性，他为什么能如此成功？因为它符合冯诺依曼原理，控制流主导，也就是通由对象的行为，指引数据的传递。也就是为什么职责，协作在OO中格外重要的原意。因为他们是刻画控制流的。
因此我的论点是，在数据模型上，OO并不占有优势。
而你所讲的问题，是数据库在流程和运算上的缺陷。但是你用的题目是OO的关系比数据关系简单，等于你用了数据视角的论点但用了动态视角的论据。mismatch！
另外，可以考虑一下在消息或者服务驱动的分布式系统中，比如SOA，数据是XML描述的，why?其一是交互性，其二是因为消息扮演了控制流的角色，OO对象已经没有用处了，用它来传递数据，并不能发挥他的作用。
最后，上述所有内容，讨论的是计算机科学范畴，不是计算机应用范畴。跟语言和java,j2ee没有任何的关系。本来深刻认识OO不足是研究OO理解OO的必然过程，但是在初学者眼中会引起恐慌。banq的论坛这里初学者很多，我对可能会产生的恐慌表示道歉。所以如果banq认为不必在这个论坛探讨，删掉就好了。