在介紹Python下的兩個(gè)ORM框架（Django和SQLAlchemy）的區(qū)別之前，我們首先要充分了解ORM框架的用途。
ORM代表對(duì)象關(guān)系映射。ORM中的每個(gè)單詞解釋了他們?cè)趯?shí)際項(xiàng)目中的用途：
因此，可以得到這樣的結(jié)論：ORM的作用是將編程語言與數(shù)據(jù)庫進(jìn)行關(guān)聯(lián)，以簡(jiǎn)化依賴于數(shù)據(jù)的應(yīng)用程序的創(chuàng)建過程。
Django ORM使用了活動(dòng)記錄的實(shí)現(xiàn)：你能在大多數(shù)的ORM庫中看到這個(gè)實(shí)現(xiàn)。這意味著數(shù)據(jù)庫中的每一行記錄都直接映射到代碼中的一個(gè)對(duì)象，反之亦然。 ORM框架（如Django）不需要預(yù)定義模式來使用代碼中的屬性。你可以直接使用它們，因?yàn)榭蚣芸梢酝ㄟ^查看數(shù)據(jù)庫模式（schema）來“理解”結(jié)構(gòu)。此外，你可以將記錄保存到數(shù)據(jù)庫中，因?yàn)樗成淇梢缘奖碇械哪硞€(gè)特定行。
SQLAlchemy使用了數(shù)據(jù)映射器的實(shí)現(xiàn)：在使用這種實(shí)現(xiàn)時(shí)，數(shù)據(jù)庫結(jié)構(gòu)和對(duì)象結(jié)構(gòu)之間是分離的（它們不像Active Record實(shí)現(xiàn)中那樣的一一對(duì)應(yīng)）。在大多數(shù)情況下，你必須使用另一個(gè)持久層來保持與數(shù)據(jù)庫的交互（例如，保存對(duì)象）。所以你不能在使用Active Record實(shí)現(xiàn)的時(shí)候調(diào)用save()方法，但另一方面，你的代碼無需知道數(shù)據(jù)庫中的整個(gè)關(guān)系結(jié)構(gòu)，因?yàn)榇a和數(shù)據(jù)庫之間沒有直接的關(guān)系。
那么他們中的哪一個(gè)贏得了這場(chǎng)戰(zhàn)斗呢？沒有。因?yàn)檫@取決于你要完成什么樣的任務(wù)。我認(rèn)為，如果你的應(yīng)用程序大部分只需用到CRUD（創(chuàng)建，讀取，更新，刪除），不同數(shù)據(jù)實(shí)體之間并沒有復(fù)雜的規(guī)則，則應(yīng)該使用Active Record實(shí)現(xiàn)（Django）。它能讓你輕松快速地為你的產(chǎn)品設(shè)置MVP，而不會(huì)有任何麻煩。如果你的應(yīng)用程序中有很多“業(yè)務(wù)規(guī)則”和限制，你好使用數(shù)據(jù)映射器模型，因?yàn)樗粫?huì)綁架你，強(qiáng)迫你嚴(yán)格按照活動(dòng)記錄的方式進(jìn)行思考。
在某些情況下，Django和SQLAlchemy可以一起使用。在實(shí)際的項(xiàng)目中我多次看到Django用于所有常規(guī)的CRUD操作，而SQLAlchemy用于更復(fù)雜的查詢，通常是只讀查詢。
有關(guān)這方面更多的信息和示例，請(qǐng)參閱BetterWorks工程博客（我們沒有與他們聯(lián)系，我們只是喜歡他們的博客帖子:)）。
兩個(gè)框架的另一個(gè)區(qū)別是，Django可以為你的表自動(dòng)創(chuàng)建主鍵，而SQLAlchemy不會(huì)這么做。你必須自己為每個(gè)表手動(dòng)創(chuàng)建主鍵。你認(rèn)為誰了解哪個(gè)主鍵適合于某個(gè)數(shù)據(jù)庫表呢？ 根據(jù)你的團(tuán)隊(duì)的知識(shí)和經(jīng)驗(yàn)，你可以自行決定。
默認(rèn)情況下，Django會(huì)自動(dòng)提交，而SQLAlchemy則不會(huì)。這會(huì)影響到你使用框架的方式（事務(wù)，回滾等）。
Django和SQLAlchemy都可以與MySQL、PostgreSQL、Oracle和SQLite一起使用。如果你正在使用MSSQL，則應(yīng)該使用SQLAlchemy，因?yàn)樗耆С諱SSQL，并且你能找到更多的相關(guān)信息和文檔。
在網(wǎng)絡(luò)上有一個(gè)很普遍的觀點(diǎn)：Django更容易學(xué)習(xí)。這可能很容易就能看出來，因?yàn)樗ǔＳ糜诓辉趺磸?fù)雜的例子。所以，你應(yīng)該考慮一下你愿意花多少精力在框架的學(xué)習(xí)上，以此來獲得使用SQLAlchemy所帶來的更多的靈活性（如果你真的需要它的話）。
毫無疑問，SQLAlchemy擁有所有Python ORM框架中的大的社區(qū)。如果社區(qū)對(duì)你來說很重要（我認(rèn)為應(yīng)該是），SQLAlchemy應(yīng)該是你的選擇。這并不意味著你找不到Django等其他框架的任何幫助。你也能收到錯(cuò)誤修復(fù)、StackOverflow中的問題解答以及你需要的任何其他幫助，但如果使用SQLAlchemy的話，你獲取幫助的機(jī)會(huì)更大。
我認(rèn)為在這里寫這個(gè)（X比Y快）是不負(fù)責(zé)任的。 由于ORM具有非常多的特性和功能，并且它們?cè)诿總€(gè)框架中都是不同的，所以很難得出哪個(gè)框架快哪個(gè)框架慢的結(jié)論。根據(jù)我的經(jīng)驗(yàn)，你使用框架功能的方式會(huì)對(duì)應(yīng)用程序數(shù)據(jù)庫層的整體性能產(chǎn)生很大的影響。所以，我建議不要因?yàn)榭蚣艿男阅芏x擇它，而是要學(xué)習(xí)如何正確地使用框架并充分利用它。
如果你使用ORM框架運(yùn)行原始的SQL查詢，則可以使用Jooq或?qū)δ承┎樵儾皇褂肙RM，你還可以看看EverSQL查詢優(yōu)化器，這可能是簡(jiǎn)單的優(yōu)化查詢的方法。
對(duì)于任何的比較，我認(rèn)為好是留給讀者自己做決定。每個(gè)例子都是不同的，不同的技術(shù)適合不同的例子。看一下上面指出的那些差異，告訴我們你終做出的決定。
本站文章版權(quán)歸原作者及原出處所有 。內(nèi)容為作者個(gè)人觀點(diǎn)， 并不代表本站贊同其觀點(diǎn)和對(duì)其真實(shí)性負(fù)責(zé)，本站只提供參考并不構(gòu)成任何投資及應(yīng)用建議。本站是一個(gè)個(gè)人學(xué)習(xí)交流的平臺(tái)，網(wǎng)站上部分文章為轉(zhuǎn)載，并不用于任何商業(yè)目的，我們已經(jīng)盡可能的對(duì)作者和來源進(jìn)行了通告，但是能力有限或疏忽，造成漏登，請(qǐng)及時(shí)聯(lián)系我們，我們將根據(jù)著作權(quán)人的要求，立即更正或者刪除有關(guān)內(nèi)容。本站擁有對(duì)此聲明的最終解釋權(quán)。
