最近看到一篇博客《》，文章举例说明了一个连表查询使用程序code来写可读性可维护性更好，但是回帖意见不一致，我想作者在理论层面没有做出更好的论述，而我今天才回帖结果发现不能回帖了，于是单独写此文随记。

  木桶定律    

    连表查询的确应该尽量避免，虽然普通情况下一条连表查询的SQL效率比两个for循环效率更高，但是我们应该知道大量依靠复杂SQL查询的应用程序，数据库很容易成为瓶颈，但应用程序所在的服务器却比较空闲，那么此时应用程序表现的结果就是等待数据库返回查询结果，总体时间更长了，这也是“木桶定律”在软件中的体现，因此，正确之道是要使得系统各个节点不要出现短板，在不使用连表查询的情况下，我们可以将表分散到不同的数据库，实现分库分表，并结合并行查询，总体上提高系统资源利用率，提高程序执行效率。

    当然，上面的结论也有前提，就是每次查询的网络IO不能成为瓶颈，否则还是在数据库中执行连接操作比较合适，如果有密集的查询并且每次涉及大量IO，这种情况下甚至应该使用存储过程，所以到底是应该写在code中还是写SQL，应该具体问题具体分析。

   二八原则

    根据绝大部分项目实际情况，80%的查询都是一些简单的单表查询和连表查询，这部分查询用ORM是很合适的，结合缓存的确能够很大程度上提升系统效率；而剩下的20%查询涉及复杂的SQL和大量的IO，此时应该直接使用SQL或者存储过程，所以一个项目我们选择数据层框架的时候，需要它既支持ORM，也支持SQL，但应该是高级别的支持SQL，集中管理或者配置SQL的形式，类似iBatis框架那样的SQL-MAP功能。如果有大量表单，还应该考虑这样的数据层框架能够支持数据控件绑定。所以一个优秀的数据层框架应该同时具备ORM，SQL-MAP,Data Controls 功能，有一款国产的值得推荐！