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

[knives ()]

我們公司同一個部門分了幾個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 會很慢

謝謝回覆

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.166.199.154
※ 文章網址: http://www.ptt.cc/bbs/PHP/M.1402146811.A.C09.html
推 hiigara:我的印象是統統用 PK 來對應且one to one 的話效能不差
→ hiigara:碰過「資料不存在的時候效能大幅變慢」的例子，細節忘了..
→ hiigara:是說走 ORM 的理由個人覺得 DB 效能不會也不該是主要考量
→ hiigara:讓 code 好寫好讀才是原因。效能考量的話手刻 SQL 總是比
→ hiigara:gen 出來的更有機會抄捷徑...
推 Xezzaosui:index 和 where 下的好，join 不會慢到哪去
→ Xezzaosui:倒是這 N+1 是怎麼回事......
→ Xezzaosui:另外，DB 效能絕對是主要考量，這超難 scale 的啊......
推 Xezzaosui:用不用 ORM 和 Query 下的好不好沒有絕對關係
→ alog:片段的程序的測試 Query 效能，再來看 Render 網頁後的速度
→ alog:用ORM或SQL都沒錯，寫不好N+1一樣會發生
→ alog:要戰效能，直接測試就知道了
→ alog:另外就是..主鍵查詢其實還蠻快的.
→ alog:資料量太大，可以partition
→ alog:不過我看你提的進度delay應該不會是這個環節.haha
推 appleboy46:原 PO 還沒逃？
→ appleboy46:個人建議遇到這種情形，你沒辦法改變整個生態的
→ appleboy46:你要是這樣用，只是黑的更快
推 hiigara:看到 soft_job 的文章..感覺問題點跟 ORM/join 沒關係 XD
→ dlikeayu:現在ORM一定有Relation相關method,不會的人跟ORM好不好無
→ dlikeayu:關啊