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