最近的政府喜欢做很多改变。其中的两条变动是：西马的产假和陪产假.
产假是孕妇的假期，西马政府把产假从60天增加到98天；陪产假是丈夫的假期，从1天增加到7天。东马暂时维持不变。
当西马的同事询问人事部时，人事部的同事就联系我并要求leave system能够cater这个case；因为我们的leave system只给他请一天假，实际上他可以拿7天。
人事部给了西马员工拿陪产假需有的条件：
1。男士
2。已婚
3。在公司服务了一年或以上
4。产期前30天通知
5。只限前五个孩子
我告知人事部我只能让leave system 查陪产假的前三项条件，人事部必须自己确认其他两项（如果他们要严格遵守的话）。
其实每到一个阶段，我都会感觉自己思考能力明显下降。以前我一接到案子，我就可以开始想该怎么做，然后按照我头脑的蓝图去立刻完成它。可是不知从几时开始，我需要时间等灵感降临，我无法一接到案子就立即行动，因为感觉还是有一些blur，有那种“不知要如何下手”的感觉。
大约两个星期后，我再回看这个case，觉得有头绪后就开始动工（毕竟前两个星期也是在忙e-invoicing system training的东西）。
我看回consultant10多年前写的 “Apply Leave” coding，然后在这个基础上添加两个新的leave type：陪产假（西马）和 产假（西马）。当然enhancement的功夫不只这一些，还要用indicator告知leave system那一个工作地点位于西马那些。
Consultant是以“删除法“coding来决定一个员工可以请什么类型的假期。举个例子：Probation staff不可以拿Exam Leave。Consultant的写法是：如果请假的员工还没过试用期，就不给他Exam leave的选项。
这篇文章我主要想表达的是以下的问题：我发现了consultant 总共分三次（3个select query)从同一个table拿同一个员工的资料。如此一来database I/O 进出三次。如果你的data size不是很大，就比如Employee Master，那么就还好，就是Performance问题不会明显。但是如果你把这个script用在data size很大的table，那么肯定就立马引发performance问题了。
什么是Performance问题？就是本来我Click Apply Leave form，那个form 一秒内就直接呈现，我就可以Apply假期了。如果今天是那种有几十万records的table，那么每一个人请假，system要进出这个table 3 次，那个 I/O (Input Output) 成本就变很高了，而且重点是完全没有必要的成本！
所以我修改了这个部分：
一个 select query拿到三个value @G, @M, @C。不仅如此，我还可以一次性拿另外三个资料，而无须再写多三个select query。
