SQLObject vs SQLAlchemy

一、簡介

隨著TurboGears 1.0的發(fā)布，郵件列表中有大量的問題詢問為什么新工程應(yīng)該使用SQLObject或者SQLAlchemy。答案是他們是可信的。

一般來說，TG1.0官方推薦使用SQLObject(以后簡稱SO)。因為有完整的支持，并且易于學(xué)習(xí)和使用。如果需要使用SQLAlchemy(以后簡稱SA)是出于SQLObject無法處理一些狀況時，常見的情況是遺留的數(shù)據(jù)庫使用了多列的主鍵。

在 TG2.0混亂的開發(fā)狀態(tài)代碼中可以看到兩個包交換了位置，SA成為了官方推薦包(by gashero)，而SO成為支持但是并不推薦的包。這可以確保你基于SQLObject的應(yīng)用不會突然停止工作，所以你使用SA是不會過時的。至少可以 選擇。在現(xiàn)在，這是一個可選項，但未來卻不是。如果你仍然猶豫不決，下面的文檔會教你做出決定。

二、什么是ORM？

首先，SO和SA是"object relational mappers"(ORMs)。他們提供了使用Python對象方便的操作關(guān)系數(shù)據(jù)庫的方法。ORMs是在手寫SQL語句之上的簡化和抽象。不使用ORM的數(shù)據(jù)庫程序需要在代碼中嵌入SQL語句。

相比于嵌入SQL，ORM更有利于代碼的簡明和易于移植。不利之處是在構(gòu)造對象時無法控制，所以你無法(必然的)線性的處理上百萬行的數(shù)據(jù)庫記錄，但是對大多數(shù)應(yīng)用程序來說，在ORM中定義和使用模型是很方便的。

你可以不使用ORM，或者不必到處使用，但是TG的很多高級功能依賴于SO或SA。

三、功能對比

SA的主要優(yōu)點：

支持組合鍵，例如你有個表的主鍵是由多個列構(gòu)成。這常見于遺留的(legacy)數(shù)據(jù)庫?，F(xiàn)在你可以重新設(shè)計你的數(shù)據(jù)庫模型。

SQL查詢的生成效率高。相同目的下，SA比SO生成更少的查詢。

多種前端接口。標(biāo)準(zhǔn)的SA接口是個數(shù)據(jù)映射模式，(by gashero)但是也可以有多種活動記錄(Active Record)接口，并且有更多的選擇。

當(dāng)然SA也有缺點：

SO的設(shè)置遵循了活動記錄(Active Record)模式，而SA使用了數(shù)據(jù)映射模式。這導(dǎo)致了SA的彈性更好，但是同樣的操作卻需要更多的代碼。實際應(yīng)用中，活動記錄模式更適合大多數(shù)WEB應(yīng)用。當(dāng)然，非數(shù)據(jù)映射的SA前端還在開發(fā)中。

SA開發(fā)周期較短，所以其接口并不穩(wěn)定而且bug頻出。例如，當(dāng)前的活動記錄前端就被替換掉了，并且MS SQL server的支持在當(dāng)前版本(0.3.1)中也有bug。

部分TG功能還無法同SA工作。主要的一個是CatWalk，模型設(shè)計器，和FastData。這在將來會得到支持，當(dāng)然在2.0版本之前，但是在1.0的開發(fā)計劃中暫時還沒有這個分支。

四、穩(wěn)定性

兩個項目都是在1.0版本之前，SA已經(jīng)開發(fā)了幾個月(by gashero)而SO已經(jīng)開發(fā)了幾年了。而在在數(shù)據(jù)庫之間的支持/穩(wěn)定性上也有區(qū)別，常見的數(shù)據(jù)庫(MySQL和PostgreSQL)就被支持的非常好。

不常見的數(shù)據(jù)庫，如MS SQL Server和Firebird雖然支持，但是支持程度有限，且沒有經(jīng)過完整的測試。

五、項目狀態(tài)

兩個工程都在開發(fā)狀態(tài)。SA更活躍一些，而SO的郵件列表冷冷清清，因為它的不成熟。

六、文檔

相比于SO，SA的文檔非常的長，有組織和完善。SO有很好的入門文檔，但是對特殊的用例你還是需要查看API文檔。

翻譯自TurboGears官方文檔。大家可以參考這篇文章來對比這兩種Python最流行的ORM框架。從作者的觀點來看還是現(xiàn)在推薦SQLObject，在不遠(yuǎn)的將來肯定推薦SQLAlchemy。