有关JOIN ON的心得体会

        在第一家公司工作大概有一年之后，我的上司开始让我负责一个项目了。

说起这个项目，其实就是类似一个报表系统的抽数据的活。我的主要工作就是将我们公司产生的数据进行抽取清理，然后生成一些带有分析性质的数据。

说干就干了，在项目开始的最初阶段，还是免不了需求分析。真的，如果不明确需求，做出来的数据再好看也是白搭。公司在沟通上有点好处就是装了腾讯通(RTX)，有什么不清楚的可以直接在上面找到相关负责人进行沟通，不需要大老远的当面去咨询，对于那时候比较羞涩的我还是挺好的一个工具。

需求分析结束了，就开始设计相关表格了，那时候还不懂数据建模，只是把一些必须的数据都往一个表里放，中间如果有转换的再建个中间表而已。虽然在我离职听说这个项目还在运行，但是感觉没完善好，这些就是后话了。那时候建表就直接在SQL Server 2008上填了，定义好主键外键以及一些约束条件就完事了，贼快了。之后就开始码代码了。因为项目不大，前前后后我一个人就能搞定，只要抽数转换的逻辑正确，一般没什么问题，但就是这个逻辑上出了点问题。

数据之间的相互关联一般都用JOIN...ON来匹配两个表之间的数据，但是在匹配的时候如果匹配的条件错了，那就是差之毫厘失之千里了。

我记得是在计算一个发货数据的时候，两个表里面都有发货数据，理论上只要匹配上这些发货数据的订单ID就OK了，但是有个表里面有个发货状态，另外一个则没有，在计算的时候由于没有确定具体的发货状态，导致计算出来的结果比实际大了好多，这归根揭底还是没有对业务了解清楚。

虽然后来这个问题解决了，但是如果我当时把匹配出来明细仔细核对一遍，一眼就看出来了。我的上司后来也教育我做数据的一定要谨慎，不能有一点不清不楚，马虎大意。技术虽然掌握了，但是怎么将技术正确的发挥还是靠人，人才是最后的执行者，得对自己的东西负责！

当时说的我真的无地自容，自己也非常惭愧，从那以后凡是涉及写操作的语句我都会先查询一遍再写入到数据库，这样才能发现你写入的数据有没有问题。而不是想当然只要逻辑正确就OK了！