項目里該不該用ORM？

01-11

最近在用python寫支付系統，正在糾結該不該用ORM來限制下

個人經驗，各個一開頭立志簡潔不用orm的項目，隨著業務複雜度提高，最後都發展出自己的一套殘缺版orm

大的項目還是推薦ORM。如果你裸寫SQL，隨著業務和人員的增加你也會試著封裝與DB連接的模塊，那麼恭喜你，你自己寫了一個ORM。

使用 ORM 的好處：

1. 避免裸寫 SQL 語句，一個是看起來簡潔，另一個是藉助 ORM 框架防止 SQL 注入

2. 將 Data 抽象為 Object，由此可以融入現有的 OO 編程方法

缺點：

1. 據說 ORM 性能不行

不過以我自身的姿勢水平，還沒到考慮 ORM 對性能消耗的地步，另外從周圍前輩們的經驗來看，基本也都推薦使用 ORM 作為最佳實踐

一開始決定不用ORM的，最終都被逼得自己重新造了個蹩腳的ORM輪子；

一開始決定使用ORM的，最終都被逼得繞開ORM自己挽起袖子裸寫SQL。

藥丸！

我覺得稍微大一點的項目，都要用，業務模型一複雜起來，如果隨便修改一個東西，我要修改很多處的話，很容易出錯。

效率問題，sqlalchemy已經為我們做到很好很好了，比我們很多人手寫的sql效率都要高。如果確實擔心效率問題，你完全可以在常用介面，手寫sql，其他還是用orm。

至於上面所說的，互聯網公司不用，更是扯淡。互聯網公司的產品迭代非常快，改動比較多，要是有200個介面，全是用sql寫，你很容易就會出錯。

我目前用flask框架作為http前端，sqlalchemy做orm，twisted用作tcp伺服器，twisted方面，基本只訪問redis，就是以為twisted本身自帶的dbpool基本都手寫sql，業務模型稍微一修改，sql語句都要找半天，真是浪費時間。

還有上面說的，多個資料庫，或者讀寫分離的，拜託，大哥，這個問題sqlalchemy不知道哪年就解決了。

還有緩存問題，我現在基本都用redis作為緩存，基礎數據redis里放一份，sql裡面放一份，同時更改。常用查詢，完全可以自己做一個緩存，這個很難嗎？

如果使用sqlalchemy 盡量使用sqlalchemy的sql expression, sqlalchemy的orm比使用sql expression要慢,而且有些事情要實現明白,否則將來代碼擴展到多個文件時會有疑惑,比方說

product = session.query(Product).get(1)

product.name = "test"

# 再查詢一些東西後再修改

sessin.query(OtherModel).fitler(....)

...

product.other_pro = "test2"

session.commit()

這裡sqlalchemy實際提交了兩次update 語句

* update products set name="test" where id=1;

* update products set other_pro="test2" where id=1;

在session.query(OtherModel)行時,實際上會先發送session.flash()

不用浪費時間。不如用。

SQLAlchemy用起來不複雜。手寫更複雜。

======

能少些代碼，就不要多寫。無論如何，這個策略錯不了。

peewee

SQLAlchemy

為什麼不用呢？？？

這個其實挺複雜。就像Python到底要不要非同步一樣：）

小項目簡單腳本上ORM會費事，所以並不建議。

大一點的項目或者變化較快的項目ORM是一個好東西，可以讓開發更加高效。

再大一些，需要考慮性能時，手寫SQL是必須的，尤其是某些場景ORM會帶來額外性能消耗，這時一般數據結構變化可能性小了很多，手寫SQL會帶來一些性能優化，可以考慮。

一般來說，幾乎所有ORM會在你需要使用sqlserver的merge語句的時候出翔，從而導致你不得不重寫所有ORM相關的代碼。這就看你的需求有沒有包含或者未來會不會包含這樣的功能了。

別考慮了

輪子現成

立馬用起

存在大量的CRUD操作的時候可以用一用現成的orm工具，減少重複的勞動，反之只需簡單的封裝下數據訪問跟模型足已。

以我的經驗互聯網項目一般不適合使用orm，比如ef，坑多，等你填完，我手寫幾句sql早就搞定了，性能更好，有問題定位起來也快，優化思路也更清晰。還有一個問題是出報表的時候複雜查詢，各種行列轉換，分組合併直接寫sql來的更直接，性能更好…

相比全自動，我更喜歡mybatis這種半自動的傢伙。我一百行的sql，你得用多少代碼來實現？你知道要改哪些？改一個邏輯牽扯多少文件？編譯上線，這是要成本的。我們那時候兩三百行的sql見怪不怪，現在的同學二三十行就說看不懂

一開始也不用、但受不了寫sql，做了個殘缺版的輪子。

why not?

再說了，object在mvc里還用得上呢

對於複雜的邏輯

可以自己寫sql啊

然後讓mapper做or映射

如果有一定功底，項目規模較大，可以自己寫一個輕量級orm框架，結合裸sql使用。

可以看下這個, 輕量的, 無需建模型

GitHub - zii/lorm: A light weight python ORM without models.

可以集成orm，最好是查詢使用裸sql，orm負責增刪改，orm的特性也不要用太多（比如主外鍵關聯啥的最好不用），這樣達到簡潔而又不用編寫大量的sql，代碼看上去更可讀

本來傾向於高效SQL，現在人多了開始用簡單ORM，提高開發效率，解決資料庫切換問題。

至於性能，可以用緩存。

我不用……

然後，我創造了輪子……

現在我的原則是，後台系統堅決用，掛在前面的網站最好不用。

orm要用好不容易，特別很多濫用級聯的，

本來用json序列化一個對象，結果序列化了一個資料庫……

所以，當你不知道用不用級聯好的時候，那還是最好不要用了……