我们公司同一个部门分了几个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 会很慢
谢谢回复

我的印象是统统用 PK 来对应且one to one 的话效能不差碰过“资料不存在的时候效能大幅变慢”的例子，细节忘了..是说走 ORM 的理由个人觉得 DB 效能不会也不该是主要考量让 code 好写好读才是原因。效能考量的话手刻 SQL 总是比gen 出来的更有机会抄捷径...

index 和 where 下的好，join 不会慢到哪去倒是这 N+1 是怎么回事......另外，DB 效能绝对是主要考量，这超难 scale 的啊......用不用 ORM 和 Query 下的好不好没有绝对关系

片段的程序的测试 Query 效能，再来看 Render 网页后的速度用ORM或SQL都没错，写不好N+1一样会发生要战效能，直接测试就知道了另外就是..主键查询其实还蛮快的.资料量太大，可以partition不过我看你提的进度delay应该不会是这个环节.haha

原 PO 还没逃？个人建议遇到这种情形，你没办法改变整个生态的你要是这样用，只是黑的更快

看到 soft_job 的文章..感觉问题点跟 ORM/join 没关系 XD

现在ORM一定有Relation相关method,不会的人跟ORM好不好无关啊