› 看板 Soft_Job 關於我們 聯絡資訊
作者MacPerson (Gary)
看板Soft_Job
標題[討論] ORM or Raw SQL
時間Sun Aug 3 22:42:36 2014
最近在開發新的專案，與同事在討論ORM的相關問題。 之前以MVC架構在開發網頁時，Model的部分還是用ado .NET，但利用Reflection 的方式，將他映射回類別，所以即使用ado來開發，但模型驗證的部分，還是可以 繼續使用。 之前會繞過ORM以ADO開發的原因是，團隊成員對SQL熟到炸了，不想為了取得資料， 來去學習ORM(學習也是成本)，另外ORM也有它的極限，需要用到一堆join跟SQL函數 時，真的不知道該怎麼把他轉為ORM的寫法... 最近的案子，突然決定Model部分全部改為ORM的方式做處理，但是一遇到棘手的複雜查詢 ，又非得回到ado的方式來做處理。 想請問大家在工作上，ado的使用者多還是ORM的使用者多? 對於複雜查詢時，又必須以ado的方式來解，或者將他包成stored procedure或view， 再用ORM去excute，這樣感覺像是再走回頭路，明明要去SQL化(物件導向)，但一遇到複 雜查詢卻又非得回到ado的方式，Programmer必須得會SQL跟ORM，在程式裡出現2種風 格的model，其實我還蠻無法接受的.... 以上跟各位分享與討論..... (此篇非抱怨文，我已經習慣ORM的作業方式，但無法說服自己，必須在model寫成2種風格) -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.234.44.74 ※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1407076959.A.511.html ※ 編輯: MacPerson (36.234.44.74), 08/03/2014 22:44:04
推 J002:小弟目前遇到狀況跟您有點類似，但是主要都是用stored 08/03 22:44
→ J002:procedure去作複雜的Update… 查詢部份，有心還是可以能湊出 08/03 22:45
→ J002:來就是了… 08/03 22:45
對阿 較複雜的操作，還真的得回ado .... 這個點我真的無法說服自己 ※ 編輯: MacPerson (36.234.44.74), 08/03/2014 22:47:47
推 J002:主要是較複雜的操作，還會有速度問題… 08/03 22:48
→ hSATAC:不衝突啊，簡單的東西用 ORM 要優化的地方另外包，很合理。 08/03 22:49
問題是 我不需要優化他 只是因為複雜操作時，又必須把它包成SP 或view，感覺就是 很想擺脫SQL 但卻又拔不掉的感覺... ※ 編輯: MacPerson (36.234.44.74), 08/03/2014 22:51:33
→ J002:同組的資深前輩也是秉持跟樓上大大說的觀點一樣… 08/03 22:50
→ J002:後來某次批次塞資料時…速度真的就有差了0rz 08/03 22:50
ORM再做批次寫入時的確是有效能影響，可能要採取類似 BULK的方式來做
推 J002:是 後來作bulk沒錯XD" 08/03 22:54
→ MacPerson:以上2位前輩說的不無道理，不過我concern的點在於，明明 08/03 22:54
→ MacPerson:ORM就要要將資料操作改為物件導向，易於pg操作與理解， 08/03 22:55
→ MacPerson:但在複雜查詢時又非得要自己串SQL?這我無法理解.... 08/03 22:56
→ MacPerson:但ORM在程式法撰寫上，的確省了不少時間.. 08/03 22:56
推 J002:有跟前輩們討論過，這點或許跟資料表正規化程度有關系？ 08/03 22:58
的確是，但無疑關聯是資料庫是目前最廣為使用的DB，勢必會做上複雜查詢 還是希望之後ORM能夠克服這些問題
→ J002:有些資料表(特別是翻新現有系統) 正規化的狀況…實在有點慘 08/03 22:59
→ J002:ORM轉SQL是系統轉的 有時看到轉出來的sql string會發現頗 08/03 23:01
→ J002:恐怖… 08/03 23:01
推 rex1224:orm沒有什麼不好,只是缺點就是效能問題,假如你的orm是用 08/03 23:04
→ rex1224:entity framework的話,你可以下中斷電在linq query的地方 08/03 23:05
→ rex1224:就可以看到他轉譯出來的sql string,有時候他真的會幫你亂 08/03 23:06
→ rex1224:做很多多餘的事情,我覺得orm對小型專案或者初期poc的系統 08/03 23:07
自從我用了ORM也像發現新大陸一樣，以前insert 的sql statement要寫一大串，現在2行 有嚇到.... 不過在複雜查詢要回過頭寫SQL 我倒是覺得無言.. ※ 編輯: MacPerson (36.234.44.74), 08/03/2014 23:10:10
→ rex1224:是好的選擇,但是大型專案就不適合 08/03 23:08
→ superpai:複雜查詢ORM辦不到有什麼不好理解的... 08/03 23:17
→ MacPerson:就是因為他辦不到，但這個技術卻繼續推，所以才無法理解 08/03 23:19
→ MacPerson:所以才跟大家分享跟討論.... 08/03 23:20
→ SecretWhale:但也沒什麼技術能真的面面俱全，都是挑著好用的部份用 08/03 23:23
→ SecretWhale:不好用的部份，就折衷或想辦法搞定。 08/03 23:23
→ SecretWhale:畢竟也不是一套拳就打天下的時代，要會變招啊。 08/03 23:24
是阿~ 謝啦 前輩 不過這篇文覽的刪了.... ※ 編輯: MacPerson (36.234.44.74), 08/03/2014 23:25:50
推 chatnoir:這篇很好啊，為什麼要刪，最近我也跟同事在爭執這個問題 08/03 23:33
→ chatnoir:事實上就是大量Insert或Update時，請用SP或T-SQL 08/03 23:34
→ chatnoir:一般狀況用ORM技術，因為這對PG來說太方便了，尤其是寫 08/03 23:35
→ chatnoir:View的時候，資料binding根本無敵好用。 已經回不去了。 08/03 23:35
推 J002:推樓上前輩…回不去了0rz 08/03 23:36
推 sing10407:我都把需要用到join等等的寫成view再產生Object 08/04 00:49
推 yyc1217:複雜的join寫成view+1 08/04 00:50
推 yyc1217:簡單的操作用ORM，大量的看能否接受慢速，不能就寫成SQL 08/04 00:52
推 mepowerlmay:沒orm我還不是寫的跟飛一樣 08/04 01:20
推 kinanson:ORM是取代ADO.NET沒錯，但ADO.NET不等於sql，你完全可以 08/04 08:35
→ kinanson:直接寫SQL把資料處理出來，放進泛型裡面再用LINQ做處理.. 08/04 08:36
→ kinanson:用過LINQ來處理之後，完全無法回去寫ADO.NET了，要效能的 08/04 08:37
→ kinanson:話，我寧願直接寫sp....不過可以挑到底什麼部份，很需要 08/04 08:38
→ kinanson:效能的，再寫SP，第一原則還是以程式碼好維護為主 08/04 08:39
推 PoloHuang:推J002 08/04 09:18
推 bejoe:既然這麼喜歡ORM,為什麼不乾脆用nosql就好 08/04 09:31
推 SansWord:因為客戶只有，也只想用 db 08/04 10:38
推 gmoz:所以ORM框架都有提供NATIVE QUERY吧(O 08/04 10:48
推 f124:案子太大要更新實體模型超悲劇的 08/04 13:22
推 matrixki:前輩說不要去看ORM的東西怎麼下Query 因為一看會發現 08/04 20:54
→ matrixki:他們真的寫得比較好... 08/04 20:54
→ rex1224:樓上不是吧....我怎麼看到的都很慘....XD 08/04 23:18
推 YahooTaiwan:樓上 那跟你的寫法有關 請參照各平台 ORM 的轉換規則 08/05 10:42
推 matrixki:推樓上 很多人用ORM沒有正確地使用它 08/05 23:05
→ matrixki:也常看到有人寫出N+1 query...... 08/05 23:05