[請益] 有人會完全不用sql 語法的join完成全部

作者: knives   2014-06-07 21:13:29
我們公司同一個部門分了幾個Team
最近因為公司商品趕上線,但是由於托某個Team的福,進度嚴重Delay
我的Team leader要求我們去支援他們
我們公司有用Framework,該framework有內建的ORM
所以我們可以用find() , findFirst() 的方式操作db,當然也可以直接下sql
後來我去支援他們debug,發現他們的code 真是有夠活用ORM
完全不用寫任何sql,全部用find findFirst跑資料出來
所以像有些表格的render資料,是跨好幾個table組出來
所以他們可能會寫成像這樣
$mainTable 代表主要的資料表
$secondModel 是第二個子table用到的model
$thirdModel 是第三個子table 的model
foreach($mainTable as $main )
{
$main["xxx"] = $secondModel::findFirst($main["id"]);
$main["yyy"] = $thirdModel::findFirst($main["id"]);
}
最後組成一個完整的資料
換作是我 可能 寫一串sql做join 就把這三個table 組出來,再丟到redis的cache
當然如果一次join太多表會造成效能問題,所以我在設計table的時候,都會先想好
當然他們會有一大堆的 bug修不完跟這個不是絕對的關係
想問 在迴圈裡面 再去執行db操作 的效能 會比 一開始join 出來 快很多嗎
因為他們那組一直很堅持不寫sql 不用join
說join 會很慢
謝謝回覆
作者: hiigara (石頭)   2014-06-07 23:51:00
我的印象是統統用 PK 來對應且one to one 的話效能不差碰過「資料不存在的時候效能大幅變慢」的例子,細節忘了..是說走 ORM 的理由個人覺得 DB 效能不會也不該是主要考量讓 code 好寫好讀才是原因。效能考量的話手刻 SQL 總是比gen 出來的更有機會抄捷徑...
作者: Xezzaosui (反‧轉‧衝‧動)   2014-06-08 00:22:00
index 和 where 下的好,join 不會慢到哪去倒是這 N+1 是怎麼回事......另外,DB 效能絕對是主要考量,這超難 scale 的啊......用不用 ORM 和 Query 下的好不好沒有絕對關係
作者: alog (A肉哥)   2014-06-08 03:10:00
片段的程序的測試 Query 效能,再來看 Render 網頁後的速度用ORM或SQL都沒錯,寫不好N+1一樣會發生要戰效能,直接測試就知道了另外就是..主鍵查詢其實還蠻快的.資料量太大,可以partition不過我看你提的進度delay應該不會是這個環節.haha
作者: appleboy46 (小惡魔)   2014-06-08 11:01:00
原 PO 還沒逃?個人建議遇到這種情形,你沒辦法改變整個生態的你要是這樣用,只是黑的更快
作者: hiigara (石頭)   2014-06-09 09:41:00
看到 soft_job 的文章..感覺問題點跟 ORM/join 沒關係 XD
作者: dlikeayu (太陽拳vs野球拳)   2014-06-10 03:45:00
現在ORM一定有Relation相關method,不會的人跟ORM好不好無關啊

Links booklink

Contact Us: admin [ a t ] ucptt.com