对象关系不匹配

关系模型中的范式如果仔细观察就是在将关系模式OO化，范式越高，整个关系模式表示的记录就越OO，不匹配问题，我们要放在对象模型的层次上来分析，有几大类(来自Gavin King的书)：

1， 粒度问题（对象有聚合，组合，子对象，而关系只有行和列两种粒度）

2， 子类型问题（关系模型没有继承策略）

3， 同一性问题（对象的比较有地址比较和值比较，而数据库呢？同一个行可以对应多个恒等对象，equls问题。

4， 关联相关问题（对象关联有一对一，一对多，多对多，但是数据库只用通过外键表达的一对一和一对多，而且没有方向）

5， 数据导航问题（关系数据我们可以通过定制sql来导航，而对象导航是渐进的，可怕的n+1问题就在这里）

面向对象能够最大改善代码的可重用性和可维护性，我们的业务逻辑是在领域模型中被执行而不是sql或者存储过程，对象层次的编码，我们可以大胆的使用各种设计模式，这些都依赖于多态的方法调用，而关系呢？本质就是一个表格或者集合，sql操作的源头和结果都是一个表格或者集合，这与Java应用程序中用来执行业务逻辑的关联对象网络大不相同，如果我们硬是要把对象持久化到关系数据库中，你会发现数据被分解了而不是被表达了，数据库的外键如果在sql中不指定连接将不会起任何作用，而对象可以自由导航。

关系和领域模型都必须包含相同的业务实体，但是一位面向对象的纯化论者给出实体建模方法与一位经验丰富的关系型数据库建模者各给出的不同，这个问题的通常解决方案是扭曲领域模型和被实现的类，直到他们和sql数据库Schema相匹配，毕竟保证数据安全是长久之计，这样就牺牲了OO的优势，关系模型是有关系理论这个数学基础的，而OO则没有严格的数学定义和理论实体，所以就找不到从数学来解释应该如何对这两种范式建立某种关系，没有优雅的转化被发现。

所以很有可能：软件开发是一种艺术，一种需要哲学素养的艺术，艺术就只能靠有艺术感觉的人来创造和享受，这个和音乐，绘画等艺术是一样的，艺术不是数学，不能够被形式化证明，但是创造艺术的过程会用到被数学可以证明的东西，比如音乐中的乐理和物理，这就好比软件开发中的OO和关系数据库。

当然数学也是艺术，抽象而冷峻的艺术，应用软件的开发大部分是技术，技术后面是思想，记得周爱民说过的一句话：我们要改变的是思想，提高的是能力，大部分人都是提高能力而不改变思想，这就是大部分人都不是大师的原因。

关系数据库不支持继承，我们可以做如下的映射，这些映射都是牺牲关系模式的范式基础的。

1， 用一个表包含所有继承层次的所有字段，然后标识列来标示是哪个类。这种映射方法最简单，但是是违反规范化的，而且有些字段要强制为NULL值，无法保证关系数据模型的数据完整性，这种映射方式性能最高，最简单。

2， 每个具体类一张表（意思就是父类不需要表），所有父属性在具体类表中重复，这种映射如果要查询父类要全部扫描子类表，而且一旦父类变化，这些字表要全部变化。

3， 每个类一张表，表里只包含所属类的属性，然后子类和父类共享外键，这种映射避免了第2种的可怕的修改，但是查询的时候要执行连接。