问题起源
今天，leader看了我写的代码，提了一个建议。我在写p2p业务系统的时候，数据库底层使用了“关联查询,left-join”，leader觉得这样性能不好。他建议，不使用关联查询，每次都是单表查询，如果需要查询关联数据，增加一次查询，然后再把两次甚至多次的数据合并。
即通过程序而不是sql，合并数据。
他的思考逻辑：
他之前在淘宝工作过，web系统对性能要求比较高。Web前端等程序可以使用分布式，量再大，多台应用服务器就可以应付了。而数据库，最多也就是主从结构，很容易成为瓶颈。使用关联查询，比较耗费性能，并且访问量大的时候，不够稳定。
他的观点：数据库的核心作用是，提供存储和查询服务，left join等高级查询不是数据库的强项。如果只是用单表，每次都很快，而且有保障，出错的可能性比关联查询小很多，而且单表查询容易做缓存，建索引。
我的思考逻辑：
我写的程序基本不考虑性能问题，因为我还没有遇到过性能瓶颈问题，可能是我参与的大多数小访问量的业务系统，而非海量普通消费者用户的大型互联网系统。
写程序，最基本的原则是，保证按时交付、质量过关、可读性强、容易维护。
如果自己去合并多次查询的数据，要多写不少Java代码，显然会增加工作量。
取舍
我们正在开发的是p2p系统，如果客户买我们的系统，运营得比较好的话，量也会比较大。为了应对潜在流量大的问题，开发还是需要注意性能。所以，我需要重构代码。这个合并数据的逻辑不难，用node.js写程序的时候，写过。把公共的合并逻辑或者方法，总结下来或写成工具方法，花的时间也可以少点。
一点实际经验
从过去的开发经验来看，我也非常只想写“单表查询的sql语句” ，非常容易写。更关键的是，针对一张表的CRUD操作，用Hibernate和Mybatis等数据库框架，可以很容易实现。多张表的CRUD API很难写。
扩展话题
象性能与效率的取舍等问题 ，在我看来都是一个“标准”或者“最佳实践”的问题。
我想把这5年多学习Web开发的经验，总结下，比如前端用哪些技术、后端Java用哪些框架、管理代码、打包部署 、备份、网站监测。
为什么想这么做呢？重复的问题，标准话之后，工作会轻松许多。
此外，虽然作为一个技术人员，我还是想通过写程序搞点外快的。 如果常见的功能，我都可以很快地实现，那么在相同的条件下，我可以实现更多的系统，只要有一个可以卖出去，比如5万一套，也是非常多的。
这些都是我的一点想法，希望有一天可以实现，哪怕只是一小部分。
小雷FansUnion-博学的互联网技术工作者
2014年10月30日
湖北武汉