ORM构架相较传统的普通型（请原谅我使用这个词，因为我不知道该使用什么来形容他）提供了先进的“对象－关系”映射，他存在最大的意义在与试图消除关系型数据库结构与面向对象编程中不可逾越的鸿沟。与激进的dlinq，ODBMS不同，他并不试图改变目前的代码构架或是数据库结构，他只是一个桥梁，试图将复杂两个完全不同的构架连接起来并提供一种简单而便捷的手段来方便别人使用。
围绕这座桥梁，无数的人员参与了它的设计与建造，而且因为意思形态的不同，围绕ORM，他们产生了无数的话题和创意。ORM由原来的设计模式转变成为了一个庞大的构架，他向想越过对象－关系之河的人们提供工具，并采用了很多方法，试图减轻使用这一工具所带来的副作用。但是，我们真的需要ORM框架吗？
下面就本人的一知半解来阐述下ORM的不足。
ORM的核心概念是O->M的转换，软件设计因为OO，而获得极大的发展，软件开发的效率得到了很大的提升。但是一个问题被引发，OO化软件编写与关系形数据持久不匹配成为了软件开发中的一个障碍。ORM就是试图将数据持久的数据转化为OO的对象的方法方便开发。这个概念相当不错，但是在实际使用中却有着不少问题。下面我一一道来。
首先，ORM是站在“对象”的观点来观察周围的一切。但是在实际中，关系型数据库存在一些不可逾越的使得限制使用ORM必须要付出相当的代价。
我们的软件模型可能不止关注与”对象”个体的属性，而在很多情况下需要对多个”对象”的属性进行研究。
比如，我需要获知一个简单类型的值，他可能是一系列对象实例的属性集合的一个描述，比如票房排名前一百的电影的导演名。可能对象”电影”是一个拥有无数属性的对象，这对面向OO编程没有什么影响，但是为了获取这个简单的值，我必须要加载符合条件的所有电影实例来进行导演名的遍例吗？如果不是一百个电影，而是前一百万个顾客名称，我估计还是不得不去加载所有顾客。或许我们可以来对象化电影的导演名，但是如果我们需要制作一个工具，用户可以决定他关注的电影范围，来观察其任一个属性（而不是展示全部属性），我们只有加载全部对象实例了。
大量的垃圾数据交互显然自不必说，为了实现我们的目的，我们只能无奈的去复杂化我们的代码，这是我们的初衷吗？这所带来的一系列的问题由谁来买单那？
另一方面，如果我关系的简单类型的值，他可能是一个与”对象”无关的描述。比如我需要知道一个连续ID列值有哪几个缺失了。ORM就无能为力了，因为我们无法描述不存在的东西。除非制造出一个专门的对象来实现，但这也是自找苦吃的方法。
第二：
对象型和关系型的基本立足点就不一致，对象型强调的是OO,关系型的核心理念是第三范式，甚至是BCNF。因为代码需要的是简单明了的对象模型，OO拥有继承和多态，喜欢的是对象具有全面的属性。比如我设计一个汽车类，他包含汽车需要的轮胎种类，出于编程的便捷性，我当然喜欢汽车会有一个属性直接表示轮胎种类。但是站在数据库的角度上，出于扩展，简化或性能的考虑，我可能被迫使用汽车－>轮胎类型号->轮胎类型名称的设计。当然，或许这可以使用一个简单的外键级联，使”轮胎类型”对象成为”汽车”对象的属性来解决问题（这里也包含上面所说的问题，无效的加载）。但是很可能的这不是一个级联，我不希望他们使用外键关联（比如数据仓库项目）。那我就必须作出牺牲原则的抉择，OO还是Relation？这是个问题。
待续。。
周末万岁！
