[討論] ORM or Raw SQL

看板Soft_Job作者 (Gary)時間9年前 (2014/08/03 22:42), 9年前編輯推噓20(20推 0噓 32→)
留言52則, 18人參與, 最新討論串1/3 (看更多)
最近在開發新的專案，與同事在討論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
推
08/03 22:44, , 1F
小弟目前遇到狀況跟您有點類似，但是主要都是用stored
08/03 22:44, 1F
→
08/03 22:45, , 2F
procedure去作複雜的Update… 查詢部份，有心還是可以能湊出
08/03 22:45, 2F
→
08/03 22:45, , 3F
來就是了…
08/03 22:45, 3F
對阿 較複雜的操作，還真的得回ado .... 這個點我真的無法說服自己 ※ 編輯: MacPerson (36.234.44.74), 08/03/2014 22:47:47
推
08/03 22:48, , 4F
主要是較複雜的操作，還會有速度問題…
08/03 22:48, 4F
→
08/03 22:49, , 5F
不衝突啊，簡單的東西用 ORM 要優化的地方另外包，很合理。
08/03 22:49, 5F
問題是 我不需要優化他 只是因為複雜操作時，又必須把它包成SP 或view，感覺就是 很想擺脫SQL 但卻又拔不掉的感覺... ※ 編輯: MacPerson (36.234.44.74), 08/03/2014 22:51:33
→
08/03 22:50, , 6F
同組的資深前輩也是秉持跟樓上大大說的觀點一樣…
08/03 22:50, 6F
→
08/03 22:50, , 7F
後來某次批次塞資料時…速度真的就有差了0rz
08/03 22:50, 7F
ORM再做批次寫入時的確是有效能影響，可能要採取類似 BULK的方式來做
推
08/03 22:54, , 8F
是 後來作bulk沒錯XD"
08/03 22:54, 8F
→
08/03 22:54, , 9F
以上2位前輩說的不無道理，不過我concern的點在於，明明
08/03 22:54, 9F
→
08/03 22:55, , 10F
ORM就要要將資料操作改為物件導向，易於pg操作與理解，
08/03 22:55, 10F
→
08/03 22:56, , 11F
但在複雜查詢時又非得要自己串SQL?這我無法理解....
08/03 22:56, 11F
→
08/03 22:56, , 12F
但ORM在程式法撰寫上，的確省了不少時間..
08/03 22:56, 12F
推
08/03 22:58, , 13F
有跟前輩們討論過，這點或許跟資料表正規化程度有關系？
08/03 22:58, 13F
的確是，但無疑關聯是資料庫是目前最廣為使用的DB，勢必會做上複雜查詢 還是希望之後ORM能夠克服這些問題
→
08/03 22:59, , 14F
有些資料表(特別是翻新現有系統) 正規化的狀況…實在有點慘
08/03 22:59, 14F
→
08/03 23:01, , 15F
ORM轉SQL是系統轉的 有時看到轉出來的sql string會發現頗
08/03 23:01, 15F
→
08/03 23:01, , 16F
恐怖…
08/03 23:01, 16F
推
08/03 23:04, , 17F
orm沒有什麼不好,只是缺點就是效能問題,假如你的orm是用
08/03 23:04, 17F
→
08/03 23:05, , 18F
entity framework的話,你可以下中斷電在linq query的地方
08/03 23:05, 18F
→
08/03 23:06, , 19F
就可以看到他轉譯出來的sql string,有時候他真的會幫你亂
08/03 23:06, 19F
→
08/03 23:07, , 20F
做很多多餘的事情,我覺得orm對小型專案或者初期poc的系統
08/03 23:07, 20F
自從我用了ORM也像發現新大陸一樣，以前insert 的sql statement要寫一大串，現在2行 有嚇到.... 不過在複雜查詢要回過頭寫SQL 我倒是覺得無言.. ※ 編輯: MacPerson (36.234.44.74), 08/03/2014 23:10:10
→
08/03 23:08, , 21F
是好的選擇,但是大型專案就不適合
08/03 23:08, 21F
→
08/03 23:17, , 22F
複雜查詢ORM辦不到有什麼不好理解的...
08/03 23:17, 22F
→
08/03 23:19, , 23F
就是因為他辦不到，但這個技術卻繼續推，所以才無法理解
08/03 23:19, 23F
→
08/03 23:20, , 24F
所以才跟大家分享跟討論....
08/03 23:20, 24F
→
08/03 23:23, , 25F
但也沒什麼技術能真的面面俱全，都是挑著好用的部份用
08/03 23:23, 25F
→
08/03 23:23, , 26F
不好用的部份，就折衷或想辦法搞定。
08/03 23:23, 26F
→
08/03 23:24, , 27F
畢竟也不是一套拳就打天下的時代，要會變招啊。
08/03 23:24, 27F
是阿~ 謝啦 前輩 不過這篇文覽的刪了.... ※ 編輯: MacPerson (36.234.44.74), 08/03/2014 23:25:50
推
08/03 23:33, , 28F
這篇很好啊，為什麼要刪，最近我也跟同事在爭執這個問題
08/03 23:33, 28F
→
08/03 23:34, , 29F
事實上就是大量Insert或Update時，請用SP或T-SQL
08/03 23:34, 29F
→
08/03 23:35, , 30F
一般狀況用ORM技術，因為這對PG來說太方便了，尤其是寫
08/03 23:35, 30F
→
08/03 23:35, , 31F
View的時候，資料binding根本無敵好用。 已經回不去了。
08/03 23:35, 31F
推
08/03 23:36, , 32F
推樓上前輩…回不去了0rz
08/03 23:36, 32F
推
08/04 00:49, , 33F
我都把需要用到join等等的寫成view再產生Object
08/04 00:49, 33F
推
08/04 00:50, , 34F
複雜的join寫成view+1
08/04 00:50, 34F
推
08/04 00:52, , 35F
簡單的操作用ORM，大量的看能否接受慢速，不能就寫成SQL
08/04 00:52, 35F
推
08/04 01:20, , 36F
沒orm我還不是寫的跟飛一樣
08/04 01:20, 36F
推
08/04 08:35, , 37F
ORM是取代ADO.NET沒錯，但ADO.NET不等於sql，你完全可以
08/04 08:35, 37F
→
08/04 08:36, , 38F
直接寫SQL把資料處理出來，放進泛型裡面再用LINQ做處理..
08/04 08:36, 38F
→
08/04 08:37, , 39F
用過LINQ來處理之後，完全無法回去寫ADO.NET了，要效能的
08/04 08:37, 39F
→
08/04 08:38, , 40F
話，我寧願直接寫sp....不過可以挑到底什麼部份，很需要
08/04 08:38, 40F
→
08/04 08:39, , 41F
效能的，再寫SP，第一原則還是以程式碼好維護為主
08/04 08:39, 41F
推
08/04 09:18, , 42F
推J002
08/04 09:18, 42F
推
08/04 09:31, , 43F
既然這麼喜歡ORM,為什麼不乾脆用nosql就好
08/04 09:31, 43F
推
08/04 10:38, , 44F
因為客戶只有，也只想用 db
08/04 10:38, 44F
推
08/04 10:48, , 45F
所以ORM框架都有提供NATIVE QUERY吧(O
08/04 10:48, 45F
推
08/04 13:22, , 46F
案子太大要更新實體模型超悲劇的
08/04 13:22, 46F
推
08/04 20:54, , 47F
前輩說不要去看ORM的東西怎麼下Query 因為一看會發現
08/04 20:54, 47F
→
08/04 20:54, , 48F
他們真的寫得比較好...
08/04 20:54, 48F
→
08/04 23:18, , 49F
樓上不是吧....我怎麼看到的都很慘....XD
08/04 23:18, 49F
推
08/05 10:42, , 50F
樓上 那跟你的寫法有關 請參照各平台 ORM 的轉換規則
08/05 10:42, 50F
推
08/05 23:05, , 51F
推樓上 很多人用ORM沒有正確地使用它
08/05 23:05, 51F
→
08/05 23:05, , 52F
也常看到有人寫出N+1 query......
08/05 23:05, 52F
‣ 更多 MacPerson 的文章
文章代碼(AID): #1JtafVKH (Soft_Job)
‣ 更多 MacPerson 的文章
文章代碼(AID): #1JtafVKH (Soft_Job)