SQLObject vs SQLAlchemy

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。

你可能感兴趣的:(一种叫做Python的小虫)