B 和C的关系是雇佣关系，
B有一个工作时间模版，起始时间-结束时间，不是固定的。
当c在每天工作时间结束后才会收到B 给发放的工资
但是有很多个B，很多个C，每个的工作时间不一样
怎么才能再C工作时间结束，自动结算工资呢？
本来之前是考虑到计划任务的，每天10点执行一个脚本
脚本里面就是判断C今天有没有发工资，没有就发，有就跳过。
但是老板说，必须要在C工作结束之后才能结工资，哎哟，我去！！！
上面说的，不知道你们能不能理解，现在真不知道该怎么办了，求大神们给支支招！！！急
上个聊天记录图片
我在想，然道要每小时执行一次脚本吗？
9 个解决方案
#1
谁能提供个思路啊？
#2
@xuzuning ，@hongmei85 @jam007god @一起混吧, 原来这里也能艾特人，大神，有空帮忙看看啊
#3
怎么算工作结束？如果到时间就算工作结束，可以用定时任务，几分钟扫一次前面时间段内有没有结束的，有就处理
#4
工作时间有没有规律啊？，比如说都是整点，结束的话。可以把计划任务执行时间设为每小时执行一次。
如果有必要。几分钟执行一次也可以。
如果有必要。几分钟执行一次也可以。
#5
就是工作时间没规律啊，所以才烦啊，除了计划任务，还有其他什么实现方法么？
反正我目前就想到了计划任务，老板不懂技术，说是怕计划任务丢包....哎，真是够了
工作时间 是半小时，1小时整数类型，然道每天要做24*2 =48 次计划任务吗？这样对性能有损耗么？
脚本里面可能要循环读取几十万的记录，在根据时间判断，要不要发自动结算，不知道能不能支撑。
反正我目前就想到了计划任务，老板不懂技术，说是怕计划任务丢包....哎，真是够了
工作时间 是半小时，1小时整数类型，然道每天要做24*2 =48 次计划任务吗？这样对性能有损耗么？
脚本里面可能要循环读取几十万的记录，在根据时间判断，要不要发自动结算，不知道能不能支撑。
#6
不用担心，计划任务会不会出错
怕出错，可以多执行几次，还可以在出错之后设置，往邮箱里发邮件报警。
怕出错，可以多执行几次，还可以在出错之后设置，往邮箱里发邮件报警。
#7
定时任务无法满足实时要求
你应在接收工作完成信息的页面中进行结算
如果没有实时性要求，则可在任何公共程序中进行判断结算
你应在接收工作完成信息的页面中进行结算
如果没有实时性要求，则可在任何公共程序中进行判断结算
#8
这个也想过，但是万一用户不打开app，这个结算不就是出错了吗、
#9
都不开的话，结算也没意义
#1
谁能提供个思路啊？
#2
@xuzuning ，@hongmei85 @jam007god @一起混吧, 原来这里也能艾特人，大神，有空帮忙看看啊
#3
怎么算工作结束？如果到时间就算工作结束，可以用定时任务，几分钟扫一次前面时间段内有没有结束的，有就处理
#4
工作时间有没有规律啊？，比如说都是整点，结束的话。可以把计划任务执行时间设为每小时执行一次。
如果有必要。几分钟执行一次也可以。
如果有必要。几分钟执行一次也可以。
#5
就是工作时间没规律啊，所以才烦啊，除了计划任务，还有其他什么实现方法么？
反正我目前就想到了计划任务，老板不懂技术，说是怕计划任务丢包....哎，真是够了
工作时间 是半小时，1小时整数类型，然道每天要做24*2 =48 次计划任务吗？这样对性能有损耗么？
脚本里面可能要循环读取几十万的记录，在根据时间判断，要不要发自动结算，不知道能不能支撑。
反正我目前就想到了计划任务，老板不懂技术，说是怕计划任务丢包....哎，真是够了
工作时间 是半小时，1小时整数类型，然道每天要做24*2 =48 次计划任务吗？这样对性能有损耗么？
脚本里面可能要循环读取几十万的记录，在根据时间判断，要不要发自动结算，不知道能不能支撑。
#6
不用担心，计划任务会不会出错
怕出错，可以多执行几次，还可以在出错之后设置，往邮箱里发邮件报警。
怕出错，可以多执行几次，还可以在出错之后设置，往邮箱里发邮件报警。
#7
定时任务无法满足实时要求
你应在接收工作完成信息的页面中进行结算
如果没有实时性要求，则可在任何公共程序中进行判断结算
你应在接收工作完成信息的页面中进行结算
如果没有实时性要求，则可在任何公共程序中进行判断结算
#8
这个也想过，但是万一用户不打开app，这个结算不就是出错了吗、
#9
都不开的话，结算也没意义