SQLObject vs SQLAlchemy
一、简介
随着TurboGears 1.0的发布，邮件列表中有大量的问题询问为什么新工程应该使用SQLObject或者SQLAlchemy。答案是他们是可信的。
一般来说，TG1.0官方推荐使用SQLObject(以后简称SO)。因为有完整的支持，并且易于学习和使用。如果需要使用SQLAlchemy(以后简称SA)是出于SQLObject无法处理一些状况时，常见的情况是遗留的数据库使用了多列的主键。
在TG2.0混乱的开发状态代码中可以看到两个包交换了位置，SA成为了官方推荐包(by gashero)，而SO成为支持但是并不推荐的包。这可以确保你基于SQLObject的应用不会突然停止工作，所以你使用SA是不会过时的。至少可以选择。在现在，这是一个可选项，但未来却不是。如果你仍然犹豫不决，下面的文档会教你做出决定。
二、什么是ORM？
首先，SO和SA是"object relational mappers"(ORMs)。他们提供了使用Python对象方便的操作关系数据库的方法。ORMs是在手写SQL语句之上的简化和抽象。不使用ORM的数据库程序需要在代码中嵌入SQL语句。
相比于嵌入SQL，ORM更有利于代码的简明和易于移植。不利之处是在构造对象时无法控制，所以你无法(必然的)线性的处理上百万行的数据库记录，但是对大多数应用程序来说，在ORM中定义和使用模型是很方便的。
你可以不使用ORM，或者不必到处使用，但是TG的很多高级功能依赖于SO或SA。
三、功能对比
SA的主要优点：
支持组合键，例如你有个表的主键是由多个列构成。这常见于遗留的(legacy)数据库。现在你可以重新设计你的数据库模型。
SQL查询的生成效率高。相同目的下，SA比SO生成更少的查询。
多种前端接口。标准的SA接口是个数据映射模式，(by gashero)但是也可以有多种活动记录(Active Record)接口，并且有更多的选择。
当然SA也有缺点：
SO的设置遵循了活动记录(Active Record)模式，而SA使用了数据映射模式。这导致了SA的弹性更好，但是同样的操作却需要更多的代码。实际应用中，活动记录模式更适合大多数WEB应用。当然，非数据映射的SA前端还在开发中。
SA开发周期较短，所以其接口并不稳定而且bug频出。例如，当前的活动记录前端就被替换掉了，并且MS SQL server的支持在当前版本(0.3.1)中也有bug。
部分TG功能还无法同SA工作。主要的一个是CatWalk，模型设计器，和FastData。这在将来会得到支持，当然在2.0版本之前，但是在1.0的开发计划中暂时还没有这个分支。
四、稳定性
两个项目都是在1.0版本之前，SA已经开发了几个月(by gashero)而SO已经开发了几年了。而在在数据库之间的支持/稳定性上也有区别，常见的数据库(MySQL和PostgreSQL)就被支持的非常好。
不常见的数据库，如MS SQL Server和Firebird虽然支持，但是支持程度有限，且没有经过完整的测试。
五、项目状态
两个工程都在开发状态。SA更活跃一些，而SO的邮件列表冷冷清清，因为它的不成熟。
六、文档
相比于SO，SA的文档非常的长，有组织和完善。SO有很好的入门文档，但是对特殊的用例你还是需要查看API文档。
翻译自TurboGears官方文档。大家可以参考这篇文章来对比这两种Python最流行的ORM框架。从作者的观点来看还是现在推荐SQLObject，在不远的将来肯定推荐SQLAlchemy。
|