问题起源
今天,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日
湖北武汉
版权声明:本文博客原创文章,博客,未经同意,不得转载。