※ 引述《ripple0129 (perry tsai)》之铭言：
: 在看过一些复杂的SQL指令后，
: 觉得这是个难以维护的东西。
: 优点自然也是有的，
: 可以少写不少程式码。
情况1.
: 而复杂的SQL指令不外乎Join了好几个Table，
: Where了好几种条件。
: 想请教各位大大对于SQL的应用上，
情况2.
: 单纯做CRUD然后给与对应的entity物件，
: 需要Join时就是Select Table出来，
: 之后再自行用程式码拼装。
: 还是下达花式SQL指令降低程式码量好？
: 然后哪一种对数据库有较轻的负担？
简单的回答
两种disk I/O 都一样。 但
对DB哪台机器来说，
情况1. CPU bound
情况2. network I/O bound
对AP哪台机器来说
情况1. 没事。
情况2. network I/O bound + CPU bound
资料量（笔数及SIZE）<<<<< network I/O 的负载，都没差。

这个解释好像是最干净的

推

　

他的情况1 2不是分别为1. 单纯做CRUD然后给与对应的entity物件，需要Join时就是Select Table出来，之后再自行用程式码拼装。2. 还是下达花式SQL指令降低程式码量好和这篇回复是的是相同案例吗? 还是我的眼睛有业障?问的是要用花式SQL直接取出资料还是将逻辑摆在程式里

精辟

2要看情况. 目前在做一个需要处理大量散工薪资计算的系统, 二十来个table十来万条记录方能产生一个员工的薪金计算结果. 丢给AP做这资料量大概会把网络拖死...当然SQL本身也有不擅长处理的事, 所以最佳解应该是把资料丢给embed到SQL server的module上跑?