ORM:object relation mapping,即对象关系映射，简单的说就是对象模型和关系模型的一种映射。为什么要有这么一个映射？很简单，因为现在的开发语言基本都是oop的，但是传统的数据库却是关系型的。为了可以靠贴近面向对象开发，我们想要像操作对象一样操作数据库。 举个例子：获取一篇文章，传统的方式先要执行一个sql检索数据
select * from post where id = 1
然后输出标题和内容使用
echo $post['title']; echo $post['content'];
上面的代码遇到面向对象强迫症者，他们会纠结死的。 所以他们想出了这个东西，在ORM里获取一篇文章可以这样：
$post = postTable::getInstance()->find(1);#会再内部执行select * from post where id = 1
然后输出：
echo $post->getTitle();
echo $post->getContent();
妈妈再也不用担心我的强迫症了^_^
高级点的应用，文章和分类是一对多关系、文章和标签是多对多关系
$cate = $post->getCategory(); //获取文章分类
echo $cate->getName(); //获取分类名
$tags = $post->getTags(); //获取一个文章的所有标签
是不是一个sql都没写就获取到我们需要的所有数据了？使用ORM可以完全不写sql而实现应用，这些ORM都替我们做了。除此之外，orm还可以隔离底层数据库层，我们不需要关心我们使用的是mysql还是其他的关系型数据库。
我知道的orm： doctrine和propel 除了orm之外还有odm，即object document mapping，对象文档映射，使用文档数据库比如mongodb时使用
对象关系映射（Object Relational Mapping，简称ORM）是一种为了解决面向对象与关系数据库存在的互不匹配的现象的技术。 简单的说，ORM是通过使用描述对象和数据库之间映射的元数据，将程序中的对象自动持久化到关系数据库中。本质上就是将数据从一种形式转换到另外一种形式。
ORM提供了所有SQL语句的生成，代码人员远离了数据库概念。从一个概念需求(例如一个HQL)映射为一个SQL语句，并不需要什么代价，连1%的性能损失都没有。真正的性能损失在映射过程中，更具体地讲，是在对象实例化的过程中。
目前PHP 开源比较有名的 ORM 有以下几个：
1、Propel
Propel是一个适用于PHP5的ORM映射(Object Relational Mapping)框架，它基于Apache Torque提供对象持久层支持。它通过XML格式的模式定义文件和相应的配置文件来生成SQL和类，它允许你使用对象代替SQL来读写数据库表中的记录。Propel提供一个生成器来为你的数据模型创建SQL定义文件和PHP类。开发者也可以十分简单的定制生成的类，我们还可以通过XML, PHP类和Phing构建工具把Propel集成到已有的应用开发框架中去.例如PHP框架symfony的1.2以前的版本就是默认使用了精简版的Propel作为默认ORM框架。
官方网站：http://www.propelorm.org/
2、Doctrine
Doctrine是一个PHP的ORM框架，它必须运行在>=php5.2.3版本上，它是一个功能强大的数据抽象层。
它的一个主要特征就是使用面向对象的方式来实现数据库查询的封转，它底层通过一个类似 Hibernate HQL的DQL的查询语句进行数据库查询，这使得开发的灵活性更强，大大减小了重复代码。相比Propel，Doctrine的优点在于它支持支持全文检索，Doctrine的文档一直就比Propel要全面丰富，社区更活跃，而且使用起来更加自然、更易阅读、更接近原生SQL。性能方面也略微优于Propel。同样你也可以可以很方便的把Doctrine集成到现有的应用框架中去，比如PHP框架symfony的1.3以后的版本将Doctrine作为默认的ORM框架，同时也可以将Doctrine和Codeigniter整合起来。
官方网站: http://www.doctrine-project.org/
3、EZPDO
EZPDO是一个十分轻量级的PHP ORM框架。EZPDO的作者的本意旨在降低复杂的ORM学习曲线，尽可能在ORM的运行效率和功能之间做一个平衡点，它是我至今用过的最简单的ORM框架，我目前还想将它集成到我的CoolPHP SDK中来，而且运行效率相当不错，功能也基本能满足需求，只不过ESPDO的更新比较缓慢。
官方网站:http://www.ezpdo.net/blog/?p=2
4、RedBean
RedBean是一个易于使用，轻量级PHP ORM框架，提供对MySQL, SQLite&PostgreSQL的支持。RedBean架构非常灵活，核心也非常简约，开发者可以很方便的通过插件来扩展功能。
官方网站：http://www.redbeanphp.com/
5、其他
国内的fleaphp开发框架基于TableDataGateway实现ORM实现；Zend Framework除了提供对 SQL 语句的封装以外，也同样实现了TableGateway、TableRowSet、TableRow的实现；还有一些类似Rails的ActiveRecord实现的解决方案。
总的来说，一般ORM框架对付简单的应用系统来说都能满足基本需求，可以大大降低开发难度，提高开发效率，但是它在SQL优化方面，肯定是比纯SQL语言要差一些，对复杂关联、SQL内嵌表达式的处理可能不是很理想。也许这主要是由于PHP本身对象持久化的问题，导致ORM效率过低，普遍比纯SQL要慢。但是这些都是有办法解决的，最基本的解决性能的方案，我们可以通过缓存来提高效率，Hibernate来说，虽然配置比较繁杂，但是它通过灵活的使用二级缓存和查询缓存极大的缓解数据库的查询压力，极大的提升了系统的性能。
http://www.gajotres.net/best-available-php-orm-libraries-part-1/
https://github.com/catfan/Medoo
ORM即Object/Relation Mapping的简写，一般称作“对象关系映射”，在Web开发中最常出没于和关系型数据库交互的地方。接口、中间件、库、包，你都可以这么称呼它。
我们可以结合PHP和MySQL，从ORM的四个核心理念来认识它：
- 简单：ORM以最基本的形式建模数据。比如ORM会将MySQL的一张表映射成一个PHP类（模型），表的字段就是这个类的成员变量
- 精确：ORM使所有的MySQL数据表都按照统一的标准精确地映射成PHP类，使系统在代码层面保持准确统一
- 易懂：ORM使数据库结构文档化。比如MySQL数据库就被ORM转换为了PHP程序员可以读懂的PHP类，PHP程序员可以只把注意力放在他擅长的PHP层面（当然能够熟练掌握MySQL更好）
- 易用：ORM的避免了不规范、冗余、风格不统一的SQL语句，可以避免很多人为Bug，方便编码风格的统一和后期维护
接下来再通过一个很基本的例子来说明一下ORM的使用，还以PHP和MySQL为例。
user这个数据模型是再普遍不过的了。假设我们有一张user数据表，结构如图：
在OOP中通常我们需要写一个对应的class User来作为user数据表的数据模型:
// 声明class User
class User{
$id;
$name;
function create(){/*...*/}
function load($id){/*...*/}
}
// 使用class User
$user = new User();
$user->name = 'fancy';
$user->create();但是通过ORM，我们可以不用去声明class User，可以直接继承ORM提供的工厂类，比如：
// 直接使用！对于熟悉MVC的亲知道这个意义之所在！
$user = new ORM('user'); // ORM都有自己的规则，这里直接使用了MySQL的表名
$user->name = 'fancy'; // MySQL的表的字段就是$user对象的成员变量
$user->save(); // 掉用ORM提供的接口函数ORM一般都针对数据模型提供了一下常见的接口函数，比如：create(), update(), save(), load(), find(), find_all(), where()等，也就是讲sql查询全部封装成了编程语言中的函数，通过函数的链式组合生成最终的SQL语句。
所以由这些来看，ORM对于敏捷开发和团队合作开发来说，好处是非常非常大的。这里就罗列一下我想到的ORM显著的优点：
- 大大缩短了程序员的编码时间，减少甚至免除了对Model的编码
- 良好的数据库操作接口，使编码难度降低，使团队成员的代码变得简洁易读、风格统一
- 动态的数据表映射，在数据表结构甚至数据库发生改变时，减少了相应的代码修改
- 减少了程序员对数据库的学习成本
- 可以很方便地引入数据缓存之类的附加功能
但是ORM并不是一个完美的东西，它同时也有其自身不可避免的缺点：
- 自动化进行关系数据库的映射需要消耗系统性能。其实这里的性能消耗还好啦，一般来说都可以忽略之，特别是有cacha存在的时候
- 在处理多表联查、where条件复杂之类的查询时，ORM的语法会变得复杂且猥琐
- 越是功能强大的ORM越是消耗内存，因为一个ORM Object会带有很多成员变量和成员函数。有一次修复bug时就遇见，使用ORM查询的时候会占用12MB的内存，而使用SQL的查询时只占用了1.7MB……
ORM就是这么一个让人又爱又恨的东西。回到我们开始的问题：“ORM到底是用还是不用？”。
Fancy个人的观点是：ORM要用！但关键部位不能用！
因为对于一般的Web应用开发来说，使用ORM确实能带来上述的诸多好处，而且在大部分情况下涉及不到ORM的不好的地方。但是在系统里面有大数据量、大运算量、复杂查询的地方，就不要用ORM。ORM的性能问题将给你带来灾难。在这些地方就可以使用纯SQL或者其他简单轻量的DB Helper库了。在详细了解ORM之后，你就可以扬长避短让ORM发挥其最大效用了。