14-oracle_数据库开发过程

前面基础知识已经学的差不多了，我们更重要的是如何应用这些基础知识在工作中，把业务的需求通过这些知识点落地，在学习具体案例之前，怎么保证我们的开发过程正确，以下几点是大家在工作中需要经常记住的。 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 个报表的总金额不一样，要是汇报到老板上面，这是一个严重的问题了，你做技术的就不得不去解释这个问题了。