为什么FleaPHP使用Table Data Gateway代替Active Record提供数据库
许多开发者很疑惑为什么 FleaPHP 以高效开发为目标，却没有提供 Active Record 模式。本文尝试详细阐述这个问题。
Active Record 是什么？
Active Record 模式中文名为“活动记录”，在《企业应用架构模式》（PoEAA）一书中定义如下：
活动记录（Active Record）：一个对象，它包装数据库表或视图中的某一行，封装数据库访问，并在这些数据上增加了领域逻辑。
举个例子来说，一个图书数据表，每一条记录就是一本图书的信息。那么采用 Active Record 时，每一本图书就是一个 Active Record 对象实例。
Active Record 因 Ruby On Rails 而流行
Active Record 之所以现在这么炙手可热，甚至许多人将 Active Record 和 ORM 划等号，完全是 Ruby On Rails 的原因。
在 Ruby On Rails 中，Active Record 除了最基本的将数据记录和一个对象互相映射外，还提供了数据（而不是对象）间关联关系的处理。例如：
一本图书有一个或者多个作者，所以每一个图书对象都和多个作者对象关联。反过来一个作者可以写多本书，所以一个作者对象也和多个图书对象关联。
在 RoR 中，我们获取一个图书对象时，自动就获得了该图书对象所对应的作者对象（本质上是图书数据对应的作者数据）。更进一步，通过图书对象关联的作者对象，我们 可以获取该作者所写的所有图书的对象实例。而这些工作，在 RoR 中只需要几行代码而已，以前我们需要写上一大段代码才能实现同样的效果。
RoR 中，对 Active Record 模式的实现完全利用了 Ruby 语言的灵活性，简短几行代码就可以定义一个关联。并且通过复杂的 ActiveRecord:Base 对象，提供了 CRUD（创建、读取、更新、删除）操作的默认处理。所以使用 RoR 时，绝大部分常见的数据库操作只需要很少量的代码就可以完成，大大提高了开发效率。
但 Active Record 模式也不是完美的，Active Record 存在不少缺点。
* Active Record 模式需要数据表结构和对象属性一一对应（至少是大部分对应），否则将难以使用 Active Record 模式；
* Active Record 模式并不能够真正适合完全面向对象的应用程序。因为 Active Record 模式本质上就要求一个对象必须和一个数据表对应。但在完全面向对象的应用程序中，数据和操作数据的方法很可能分布在各个不同的对象中，这些对象却并没有和 某一个数据表完全对应，而且 Active Record 无法很好的处理对象的继承、聚合等面向对象常见的对象间关系；
* 随着逐渐向 Active Record 添加业务逻辑，Active Record 对象中会混入越来越多的 SQL 语句，这在更复杂的项目中显然是一个不利因素。
如果在 Active Record 模式中添加了对数据关系（注意，不是对象关系）的处理，那么还要注意性能问题：
假如一个 Active Record 对象有多个关联。那么我取出一个对象时，很可能就连带取出了其他不少对象。但这些对象可能根本就是本次操作用不上的。其次，将对象更新到数据库时，也需要对关联的对象进行处理，否则对关联对象的修改就会丢失。
虽然可以用各种技巧来避免这些情况，但毫无疑问需要开发者对 RoR 的 Active Record 很熟悉才行。否则看上去很简单的代码，背后则会是噩梦般的数据库操作。
其次，假设我们要将数据库中每本书的单价减半，那么采用 Active Record 模式时，就必须首先读取所有的记录并实例化为对象，然后更新对象属性，再写回数据库。可想而知这样会有多差的效率。
当然了，实际开发中没有人会这样做。开发者会编写一个单独的方法，用一条 SQL 语句完成对批量数据的更新。但也说明 Active Record 模式不适合批量处理数据，而现实世界中，批量处理数据的需求随处可见。
不过由于 RoR 对开发效率戏剧性的提高，所以对于追求开发效率的项目，RoR 是一个很不错的选择。而且性能上的不足可以通过更新硬件或者配合其他技术手段来改善（例如 FastCGI 通常是运行 RoR 应用的首选）。因此在现实世界中，37signals.com 公司的所有基于 RoR 开发的应用，都获得了良好的性能表现（但是同等的硬件，跑 PHP 开发的同样功能应用是更好还是更差呢？这个问题没有答案）。
Active Record 与 ORM
许多人将 Active Record 与 ORM 划等号，这是错误的。
补充：Php教程,Php常用代码 
