作者knives ()
看板PHP
标题[请益] 有人会完全不用sql 语法的join完成全部
时间Sat Jun 7 21:13:29 2014
我们公司同一个部门分了几个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://webptt.com/cn.aspx?n=bbs/PHP/M.1402146811.A.C09.html
1F：推 hiigara:我的印象是统统用 PK 来对应且one to one 的话效能不差 06/07 23:51
2F：→ hiigara:碰过「资料不存在的时候效能大幅变慢」的例子，细节忘了.. 06/07 23:52
3F：→ hiigara:是说走 ORM 的理由个人觉得 DB 效能不会也不该是主要考量 06/07 23:54
4F：→ hiigara:让 code 好写好读才是原因。效能考量的话手刻 SQL 总是比 06/07 23:56
5F：→ hiigara:gen 出来的更有机会抄捷径... 06/07 23:57
6F：推 Xezzaosui:index 和 where 下的好，join 不会慢到哪去 06/08 00:22
7F：→ Xezzaosui:倒是这 N+1 是怎麽回事...... 06/08 00:23
8F：→ Xezzaosui:另外，DB 效能绝对是主要考量，这超难 scale 的啊...... 06/08 00:25
9F：推 Xezzaosui:用不用 ORM 和 Query 下的好不好没有绝对关系 06/08 00:33
10F：→ alog:片段的程序的测试 Query 效能，再来看 Render 网页後的速度 06/08 03:10
11F：→ alog:用ORM或SQL都没错，写不好N+1一样会发生 06/08 03:10
12F：→ alog:要战效能，直接测试就知道了 06/08 03:11
13F：→ alog:另外就是..主键查询其实还蛮快的. 06/08 03:13
14F：→ alog:资料量太大，可以partition 06/08 03:14
15F：→ alog:不过我看你提的进度delay应该不会是这个环节.haha 06/08 03:16
16F：推 appleboy46:原 PO 还没逃？ 06/08 11:01
17F：→ appleboy46:个人建议遇到这种情形，你没办法改变整个生态的 06/08 11:01
18F：→ appleboy46:你要是这样用，只是黑的更快 06/08 11:02
19F：推 hiigara:看到 soft_job 的文章..感觉问题点跟 ORM/join 没关系 XD 06/09 09:41
20F：→ dlikeayu:现在ORM一定有Relation相关method,不会的人跟ORM好不好无 06/10 03:45
21F：→ dlikeayu:关啊 06/10 03:45