关于员工出勤数据计算的问题

Question

公司的排班班如下,需要通过排班表计算员工每天的出勤数,想了许久没个好的方法,在这里请高手指点:

Answer 1

楼主的图片没有显示，没有表的结构怎么给解决问题？把图片上传csdn相册中就可以显示了。

Answer 2

考勤表的数据结构就是:
工号:PersonCode
打卡时间：CheckTime
打卡类型：上班或下班

Answer 3

你的那个排班表太复杂了吧一般的计算方法是select
  PersonCode,
  sum(case when CheckTime<=上班时间 and CheckTime>=下班时间 then 1 else 0 end) 
from
  tb
group by
  PersonCode就可以了

Answer 4

考勤处理是个非常复杂的过程, 考勤的处理过程用存储过程写了1.3W行(处理一个员工一天的考勤)
目前来讲比较通用考勤系统分为基础数据 + 单据部分 + 报表部分
基础数据应该从考勤方案入手设计, 不同的部门、职位、月薪、员工类型可以使用不同的考勤方案。
考勤方案就能规定所有的考勤细节(主要是规定工时(出勤、加班、请假、迟到、早退、缺勤、出差、夜班、休息、签卡次数等)如何计算)。考勤方案从设计的角度来讲，就是对考勤规则进行封装，考勤方案内部可以使用排班、智能认别，甚至两者结合，也可以规定该方案算不算迟到，多少分钟算迟到，算不算加班，加班单位时间是多少等，总之考勤方案规定了所有的计算规则，即只要知道某员工的、某部门、某职位的考勤方案，就知道如何计算考勤了。那么不同的部门、职位、员工类型等有不同的计算规则时，则可以分配不同的考勤方案, 设计上就形成员工 与 考勤方案之间对应关系, 这种离散关系可以系统非常灵活，做到特殊的员工特殊方案，没有特殊就用通用方案，这种离散关系可以处理集团企业，不同的分公司可以使用不同的方案。离散关系可以应用系统设计的其他方面，例如计件系统，可以设计成计件方案，那么不同的员工不同的工序可以使用不同的计件方案；例如销售系统的报价定义，首先设计出报价方案表，至于这个报价方案内部怎么算暂时不管，再可以定义不同的客户可以使用不同的报价方案表，不同的级别的客户使用不同的报价方案表，不同地区的、不同季度的使用不同的方案表，甚至国庆节可以使用不同的报价方案表，这样系统可以根据优先查找算法找到对应的唯一的报价方案表，再把报价方案表的ID)交给报价方案系统去处理出单价返回给调用者就可以了。像排班系统也可以考虑根据不同对象(部门、职位、员工、员工类型、薪别等)不同的员工归类进行排班, 还存在继承关系，例如已经仓库部门排了班次，那么仓库的员工没有特别规定的情况下，就应当继承部门的排班。
从设计的角度还需要考虑正常与非正常情况，正常的班次已经排好了，突然某个部门今天就不上班了如何处理，是否在原来的排班基础上改，还是另写单据来处理呢？从系统设计的原则来讲，事物的处理应当留下证明(单据), 尽量考虑使用单据来处理这些非正常情况。
以上是个人设计系统时体会出来的，对事物进行归类形成不同的方案，这些方案是独立存在的，可以与事物没有直接关系，然后再通过对应表进行关系，
这个对应表可以规定不同的时间段、不同的对象使用不同的方案，这样的处理可以从时间、对象两个方面灵活地处理企业不同的变化。
例如BOM表，可以把BOM单独设计出来，这时与产品没有直接关系，然后再通过对应表把产品与BOM联系起来，这样有什么好处呢
这样可以把不同的产品使用同一个BOM，不同的产品BOM是相同的，只是BOR不同而已，也可以做到同一个产品不同的时段使用不同的BOM，
甚至可以在新产品没有确认的情况下，使用BOM做独立做成本分析预算，MRP分析预算。

Answer 5

上述的重点除了说明排班的注意事情，还想表达一个设计思想：对象、方案, 对象方案对应表
对象可以表示员工、部门、职位, 员工类型、客户、客户等级、客户区域、部门 +职位等可任意组合的, 
方案可以表示对象所有可用到的规则,例如考勤方案、计件方案、信用额度方案、报价方案等。
对象方案对应表用来关联对象与方案之间的关系, 这种思想可以做到低耦合(对应关系是低耦合)、高内聚（方案是内聚的), 也符合系统的设计要求(封装、继承、分层等)
下面通过说明这样的设计思想不同地方，以售销信用额度为例。
按照常规的设计思想，根据客户、或者客户类型、或者销售部门直接设定信用额度, 像金蝶的信用额度是这么设计的, 这样的设计是高耦合的, 假设客户提出来要根据不同的地区，不同的销售方式(经销、直销、OEM)、不同的地区不同的销售方式不同的信用额度时则没有办法了，甚至遇到经济危机时需要调整不同的客户的额度时则更加没有办法。如果采用方案的思想设计，则可以根据不同的规则定义出N个不同的信用额度方案。
然后根据对象方案关系表进行设定则可以自由组合，而且可以设定不同时段有不同的信用额度。在系统求解信用额度时，也非常简单统一，
第一步 系统根据日期、客户查找出适合的信用额度方案。
第二步，把信用额度方案ID，交给信用额方案函数求解就可以了.这样的好处调用者只要把信用额方案ID传递过去，至于信用额度内部如何求解是内部的事情，而且信用额度内部计算规则改了，也与调用者没有关系，因为传递的参数只有一个ID及客户的ID.这样的对应关系设计可以解决客户提出不同的信用额度要求，只有变更对应关系就可以了，而且信用额度方案改了，则用到该方案的客户都会跟着变，从而避免一个一个客户地改信用额度。