前面基础知识已经学的差不多了，我们更重要的是如何应用这些基础知识在工作中，把业务的需求通过这些知识点落地，在学习具体案例之前，怎么保证我们的开发过程正确，以下几点是大家在工作中需要经常记住的。
1：理解源头数据业务含义和格式。
我们在做任何开发之前，都应该熟悉源系统的业务，理解后台表里的数据格式，以及业务系统的展示情况，如果可以模似一次完整的业务流程，加深理解。其实一个业务系统最主要的核心表也可能就哪么2-3个了，其他都是一些辅助表，维护基础信息的。
2：step by step
在开发的过程中，我们需要保证自己的每一步是正确的，按预期的来，可以理解为软件里的单元测试。我们在做每一步处理后需要验证我们的结果是否预期一样。比如在处理之前上一个临时表的数据记录是100条，金额是1000，我在下一步加工后，需要验证数据记录和金额是否还和上面一样，如果发生变化是否是合理的(inner join会出现少记录)，防止笛卡尔使记录数和金额增加。
3：尽量使用left join
Left join的一个好处是不会让主表的数据丢失，对一些不符合条件的记录打上标识，在下游应用时再过滤掉不符合要求的记录，这样方便历史数据问题的跟踪和定位，如果使用了inner join就直接把不符合条件的记录过滤，如果以后用户问到我系统明明就有100万的金额，为什么你的结果只有90万，另外10万呢，这时候你就可以去查历史数据了，一查明细发现，原来可能是前端数据格式不满足，少了部门维度或少了客户维度等等，导致不符合要求在应用的时候过滤了，跟据标识可以直接把10万的明细数数据导出来，推动前端系统做好数据校验，不然你就很被动天天被用户查这个问题哪个问题的。
4：BSL思想
大家在接需求的时候，因为下面是各个处室的同事，每个人的思路不一样，看数的角度不一样，他们提交上来的报表需求，你会发现很大一部分是相同的。只是某些地方不同，比如A想看到的数据是部门+客户+金额，B想看到的是部门+销售员工号+金额，C想看到的数据只有部门+金额，如果我们对每个需求都从头开发，需要做3套程序，你会发现他们的所有需求里，都是围绕部门+客户+销售员工号+金额这些在看数， 哪么我把这些需求整合在一起，做成一个宽表，里面包含这些维度和度量的基表，后续的报表直接从这个基表里做一些group by就得到结果了，以后我们只需要维护这个基表就行了，不需要维护3套程序了。减少工作量，另一个好处是，如果按3大程序来做，某天整个业务有变化，哪么逻辑也是需要更改的，因为时间太久，你只改了其中2个报表逻辑，另一个没有改，导致这3个报表的总金额不一样，要是汇报到老板上面，这是一个严重的问题了，你做技术的就不得不去解释这个问题了。
更多技术文章请关注公众号(长按后点识别图中二维码):
