OOP和RDBMS不匹配，谁向谁妥协，还是找个和稀泥的？

OOP和RDBMS不匹配        OOP的面向对象理论和RDBMS所基于的关系理论本来就不是一回事，理论不同，不匹配是很正常的事情，主要有以下表现：
粒度   为了概念的清晰和责任的单一，对象的设计粒度比较细。比如，一个User对象包含一个Address对象，Address里面有country, city, street等属性。但是，为了性能等方面的考虑，数据库表的设计粒度相对较粗，就上例来讲，可能有一个只有User表，地址方面的country, city和street等只作为字段。多态   多态是OO的特性，继承结构是很常见的，但是RDBMS则没有多态。标识   就Java而言，对象标识是reference，一般判断对象是否相同是用equals()方法，而数据库表中的一行的标识是主键关联   一个对象同其他对象发生关联，是通过持有其他对象的reference来表示，并且有方向，可以是单向，也可以是双向，可以一对一，一对多，多对多。RDBMS中的两个表关联是通过外键，并且只有一个方向，只能一对一或多对一，如果要多对多则需要加关系表了。        OOP和RDBMS的矛盾是在所难免的，就像两兄弟吵架，日子还是要过，我们的程序还是要写的。解决不匹配的问题，一般就下面三招：向RDBMS妥协   这是最常见的了，既然你是“关系”数据库，那我不OO了还不成吗？数据库表结构建好了，我就围绕着这些个表编程。不管是直接上SQL还是用大量只包含数据的VO，总之，面向过程。好处是，容易理解，这样程序员最好找；不足嘛，技术上和业务上的重复代码都太多，难以维护，没有审美，只有疲劳。向OOP妥协，用面向对象数据库   这个不说了，我还没见过传说中的面向对象数据库，并且在可预见的将来继续看不见。用个和稀泥的作中介，安抚两方   该OOD/OOP咱还OO，该用关系数据库咱还用，找个ORM工具让两方各得其所。这也许是最好的解决方案了，就算不能解决全部的问题，能解决九成的问题，就大大的节省了我们的时间，并且大大的提高了系统的可维护性。谁都知道，Java世界里，ORM实事上的标准是Hibernate。