简介一份针对酒店员工管理系统的计算机专业毕业论文设计文档适合计算机相关专业学生参考选题、结构撰写与系统开发实现。内容围绕SSM框架、MySQL数据库、HTML及B/S架构展开完整覆盖课题背景、可行性分析、系统流程图、用例图、数据库设计、界面实现和系统测试等章节并提供了管理员、普通管理员、员工三种角色的权限划分与功能模块说明对毕业设计或课程项目的落地具有较强的参考价值。资源为1个docx文档大小约970KB包含论文全文共32页目录结构清晰便于直接查阅和续写。目前已吸引201人浏览学习适合需要快速搭建毕设框架或借鉴论文格式与设计思路的读者。1. 酒店员工管理系统为什么值得自研而不是采购通用人事 SaaS酒店一线员工的排班规则远比写字楼里的固定工时复杂客房部按当天退房清房量安排班次餐饮部同时排早中晚三班前台经常需要跨零点换班。通用人事软件把排班考勤收敛在“固定上下班时间 加班审批”这套模型里到了酒店场景就出现班次结束时间早于开始时间、月度工时浮动、换班需多人确认等兼容成本。与其年年付定制开发费用不如按酒店的真实流程做一套员工管理系统把排班、打卡、考勤汇总和人员状态放进同一个数据库。这篇内容要做的就是从一个可落地的设计和实现出发先讲清楚数据库表怎么设计再给出后端接口写法、前端操作界面最后落到上线前必须处理的冲突检测、权限和离职交接问题。2. 数据库模型设计员工档案、排班、考勤三张表的约束关系决定一个酒店员工管理系统的开发成本通常先看数据模型。人、某一天、某个时间段这三类信息如果混在一张表里后期加需求时往往要重构。常见做法是拆成三张核心表员工表存相对静态的档案排班表描述未来某个员工在哪个时间段应该在岗考勤表记录实际的打卡结果。下面是这套设计的建表 SQL 和字段取舍。2.1 员工表员工工号与部门关联的取舍CREATE TABLE emp ( emp_no VARCHAR(20) NOT NULL COMMENT 员工工号全局唯一, emp_name VARCHAR(50) NOT NULL COMMENT 员工姓名, dept_id INT NOT NULL COMMENT 部门ID关联dept表, position VARCHAR(30) NULL COMMENT 岗位前台/客房/餐饮/工程, phone VARCHAR(15) NULL COMMENT 手机号用于登录和通知, hire_date DATE NULL COMMENT 入职日期, status TINYINT NOT NULL DEFAULT 1 COMMENT 1在职 0离职, PRIMARY KEY (emp_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;员工表的主键建议直接用员工工号不使用自增 ID。酒店行业里员工工号本身就有业务含义比如前台以 Q 开头、客房以 K 开头并且员工离职后工号会被回收给后续入职的人。如果使用自增主键回收工号会导致历史和未来数据关联混乱。dept_id 单独存不要直接写“客房部”这样的字符串因为部门改名字时只需要改部门表一行记录。2.2 排班表用 shift_date 加 start_time/end_time 表达跨天班次CREATE TABLE schedule ( id BIGINT NOT NULL AUTO_INCREMENT, emp_no VARCHAR(20) NOT NULL COMMENT 关联emp.emp_no, dept_id INT NOT NULL COMMENT 冗余部门ID按部门快速过滤, shift_date DATE NOT NULL COMMENT 班次日期, start_time TIME NOT NULL COMMENT 上班时刻, end_time TIME NOT NULL COMMENT 下班时刻允许小于start_time表示跨天, shift_type VARCHAR(10) NULL COMMENT 早班/中班/夜班, PRIMARY KEY (id), UNIQUE KEY uk_emp_date (emp_no, shift_date), KEY idx_dept_date (dept_id, shift_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;排班表有两个容易踩坑的设计点。第一UNIQUE KEY uk_emp_date限制了同一个员工同一天只能有一条排班这是防重复录入最便宜的手段排班界面后端保存时不用再做一次存在性检查。第二end_time 允许小于 start_time用来表示跨天班次比如前台夜班 22:00 到次日 06:00就存 start_time22:00、end_time06:00。查询展示时前端能直接显示但计算工时或做冲突检测时需要对这种记录单独处理后面第 5 章会给出具体做法。dept_id 冗余在这里是为了避免每次按部门查排班都要先关联员工表再取部门。2.3 考勤表打卡记录的幂等约束CREATE TABLE attendance ( id BIGINT NOT NULL AUTO_INCREMENT, emp_no VARCHAR(20) NOT NULL COMMENT 关联emp.emp_no, work_date DATE NOT NULL COMMENT 出勤日期以排班shift_date为准, clock_in DATETIME NULL COMMENT 实际上班打卡时间, clock_out DATETIME NULL COMMENT 实际下班打卡时间, is_late TINYINT NOT NULL DEFAULT 0 COMMENT 1迟到, is_early TINYINT NOT NULL DEFAULT 0 COMMENT 1早退, source VARCHAR(10) NULL COMMENT 打卡来源ipad/手机/门禁, PRIMARY KEY (id), UNIQUE KEY uk_emp_workdate (emp_no, work_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;考勤表的唯一键是 (emp_no, work_date)一个员工同一天只能有一条考勤汇总。实际打卡时如果已经存在记录就更新 clock_in 或 clock_out而不是再插入一行否则月度统计时同一个人的迟到次数会被重复累计。work_date 使用排班表中的 shift_date而不是自然日。原因在于跨天班次夜班员工 22:00 上班、次日 06:00 下班两次打卡跨了两个自然日但如果按自然日拆分一次班次就会被拆成两条考勤记录统计口径会乱。三张表的约束关系可以汇总成下面这个表用于评审时快速对齐表名唯一键约束目的empemp_no员工身份全局唯一schedule(emp_no, shift_date)一人一天只能有一条排班attendance(emp_no, work_date)一人一天只能一条考勤汇总3. 后端接口设计与实现排班查询、打卡校验与月度汇总后端部分常见实现是 Spring Boot 3.x 配合 MyBatis。选择 Spring Boot 是因为排班、打卡这类接口本质上是少量表的新增和查询它的自动配置能省掉大量模板代码MyBatis 则方便把复杂 SQL 写在 XML 里后续调整统计口径不用重新编译依赖的 service 层。下面按接口拆开讲。3.1 工程结构与依赖按接口划分模块dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId /dependency代码里我习惯按接口组织 controller 和 service而不是按实体类组织。一个排班相关接口对应 ScheduleController、ScheduleMapper一个考勤相关接口对应 AttendanceController、AttendanceService。这样加需求时影响面最小比如“排班增加批量复制上周”只改 Schedule 相关文件不会碰考勤逻辑。Mapper XML 放在 resources/mapper 目录接口和 SQL 分开方便 DBA 评审慢查询时直接打开 XML 看语句。3.2 按部门查询一周排班时间范围参数化RestController RequestMapping(/api/schedule) public class ScheduleController { private final ScheduleMapper scheduleMapper; public ScheduleController(ScheduleMapper scheduleMapper) { this.scheduleMapper scheduleMapper; } GetMapping(/week) public ListScheduleVO week(RequestParam Long deptId, RequestParam String weekStart) { LocalDate start LocalDate.parse(weekStart); LocalDate end start.plusDays(6); return scheduleMapper.selectByDeptAndRange(deptId, start, end); } }select idselectByDeptAndRange resultTypeScheduleVO SELECT s.emp_no, e.emp_name, s.dept_id, s.shift_date, s.start_time, s.end_time, s.shift_type FROM schedule s JOIN emp e ON s.emp_no e.emp_no WHERE s.dept_id #{deptId} AND s.shift_date BETWEEN #{start} AND #{end} AND e.status 1 ORDER BY s.shift_date, s.start_time /select这里 weekStart 由前端传周一日期格式固定为 yyyy-MM-dd后端用LocalDate.parse解析再加 6 天得到周日。接口返回的是平铺的排班记录不是组装好的日历结构因为不同门店的排班展示方式不同有的按周表格看有的按人看列表后端只返回原始排班记录由前端决定怎么渲染。SQL 里BETWEEN是闭区间正好覆盖一周七天。JOIN emp 并过滤 status1是为了不把已离职员工的排班展示给排班主管。3.3 打卡校验迟到判定的时间基准来自排班而非固定时刻public Attendance clockIn(String empNo, LocalTime clockTime) { LocalDate today LocalDate.now(); Schedule schedule scheduleMapper.selectByEmpAndDate(empNo, today); if (schedule null) { throw new BizException(今天没有排班不能打卡); } boolean isLate clockTime.isAfter(schedule.getStartTime()); Attendance att attendanceMapper.selectByEmpAndDate(empNo, today); if (att null) { att new Attendance(); att.setEmpNo(empNo); att.setWorkDate(today); att.setClockIn(LocalDateTime.of(today, clockTime)); att.setIsLate(isLate ? 1 : 0); attendanceMapper.insert(att); } else { att.setClockIn(LocalDateTime.of(today, clockTime)); if (isLate) { att.setIsLate(1); } attendanceMapper.update(att); } return att; }这段逻辑的核心是“早退和迟到都是相对于这个员工当天的排班时间来判断的”而不是统一用 9 点作为迟到线否则夜班员工永远会被判迟到。isLate一旦置为 1 就不再清除因为员工发现迟到后重新打卡不应该把迟到覆盖掉这是酒店考勤管理的常见规则。同一个员工一个自然日内的第二次打卡走 update 分支保证 attendance 不会出现重复记录。3.4 月度考勤汇总在 SQL 里聚合而不是在内存里计数select idsummaryMonthly resultTypeAttendanceSummaryVO SELECT emp_no, COUNT(*) AS work_days, SUM(is_late) AS late_days, SUM(is_early) AS early_days, SUM(TIMESTAMPDIFF(MINUTE, clock_in, clock_out)) AS work_minutes FROM attendance WHERE work_date BETWEEN #{startDate} AND #{endDate} GROUP BY emp_no /select月度汇总直接在 SQL 里做聚合而不是把所有考勤记录加载到内存再一层层 for 循环加总。几十个员工的单月记录看起来不多但按年查询或连锁酒店多门店汇总时内存方式会把单次请求的耗时从几十毫秒拉到几秒。注意work_minutes对这个统计方式是基于打卡的实际时间差计算的跨天班次因为 clock_out 是完整的 DATETIME包含日期所以 TIMESTAMPDIFF 结果天然正确真正需要修正跨天问题的是排班冲突检测也就是第 5 章的内容。4. 前端管理界面与交互部门树、排班表格和编辑状态酒店员工管理系统的前端最重要的页面就是“排班管理”。它要同时解决两个问题让排班主管快速看清一周内每个部门的人怎么安排以及让修改班次的操作尽量少点几下鼠标。常见实现是 Vue 3 Element Plus左侧部门树右侧排班表格。4.1 页面结构左侧部门树加右侧排班表格template el-container el-aside width220px el-tree :datadeptTree node-keyid :props{ label: name, children: children } node-clickonSelectDept / /el-aside el-main el-table :datascheduleRows border el-table-column propempName label员工 width100 / el-table-column propshiftDate label日期 width110 / el-table-column propstartTime label上班 width80 / el-table-column propendTime label下班 width80 / el-table-column label班次 width120 template #default{ row } el-select v-modelrow.shiftType sizesmall el-option label早班 value早班 / el-option label中班 value中班 / el-option label夜班 value夜班 / /el-select /template /el-table-column /el-table /el-main /el-container /template部门树的数据结构是{ id, name, children }与后端 dept 表的父子关系对应。排班表格每一行代表一个员工某一天的排班。el-select直接放在表格列里主管点开下拉就能改班次不需要先选中行再点“编辑”按钮。这个交互对高频换班的酒店场景很重要早餐班临时缺人时主管能在 10 秒内改完三四个人的班次。4.2 数据加载调用一周排班接口并对应渲染import { ref, onMounted } from vue const deptId ref(null) const weekStart ref() const scheduleRows ref([]) async function loadWeek() { const params new URLSearchParams({ deptId: deptId.value, weekStart: weekStart.value }) const res await fetch(/api/schedule/week?${params}) if (!res.ok) { throw new Error(加载排班失败) } scheduleRows.value await res.json() } onMounted(() { weekStart.value getMonday(new Date()) loadWeek() })这里的 fetch 调用对应第 3.2 节的排班接口前端把当前选中部门和本周周一日期传给后端。getMonday是一个工具函数把当前日期规整到本周周一。接口返回的每个字段直接映射到表格列后端返回 null 的 end_time 字段表格会显示为空代表这个员工当天没有排班。实际操作中点击左侧部门树节点就重新调一次loadWeek()并把 scheduleRows 清空避免上一个部门的排班残留显示在表格里。给表格加v-loading指令在请求发出期间显示 loading 遮罩防止主管在数据还没回来时误改旧数据。4.3 批量保存编辑后的排班如何提交到后端async function saveRows() { const body scheduleRows.value.map(row ({ empNo: row.empNo, shiftDate: row.shiftDate, startTime: row.startTime, endTime: row.endTime, shiftType: row.shiftType })) const res await fetch(/api/schedule/batch, { method: PUT, headers: { Content-Type: application/json }, body: JSON.stringify(body) }) if (!res.ok) { alert(保存失败请检查是否有重复排班) } }前端不按行提交而是把当前表格所有行做成数组一次提交对应后端批量更新接口。这样做的好处是主管可以连续改多行后统一保存网络请求次数少数据库也能用事务保证这一批排班要么全部成功要么全部失败。后端 batch 接口的常见做法是逐条执行 upsert即存在则更新、不存在则插入然后整体提交事务。前端交互动作与后端接口的对应关系可以整理成一张表新成员接手时看这张表就能定位代码前端动作请求地址方法切换部门/加载一周排班/api/schedule/week?deptIdweekStartGET修改班次下拉框无请求本地暂存-批量保存排班/api/schedule/batchPUT查看员工某月考勤/api/attendance?empNomonthGET5. 上线前必做的三类验证与参数调优系统能跑通不等于能上线。酒店员工管理系统最容易在三个边界出问题排班重叠、越权查看、离职员工的排班残留。这三类问题都和数据写入规则有关放到上线前去验证比事后补数据要轻松得多。5.1 排班重叠检测用分钟化区间处理跨天班次跨天排班让冲突检测不能直接用 TIME 比较否则 22:00 到次日 06:00 和 05:00 到 07:00 会被误判为不重叠。我一般会在接口层把时间转成当天分钟数再比较private boolean isOverlap(Schedule existing, LocalTime newStart, LocalTime newEnd) { int exStart existing.getStartTime().toSecondOfDay() / 60; int exEnd existing.getEndTime().toSecondOfDay() / 60; if (exEnd exStart) { exEnd 1440; } int nStart newStart.toSecondOfDay() / 60; int nEnd newEnd.toSecondOfDay() / 60; if (nEnd nStart) { nEnd 1440; } return nStart exEnd exStart nEnd; }核心思路是把跨天班次的结束时间加上 1440 分钟再判断两个区间是否重叠。这个判断要嵌在批量保存接口里对每个员工的每条新排班与库里已有排班遍历比较发现有重叠就整批回滚并提示是哪一天冲突。5.2 权限边界部门主管接口必须带数据范围参数酒店员工管理系统的排班权限通常按部门隔离客房部主管不应该看到餐饮部的排班。后端查询 SQL 里除了 deptId 还要加一个当前登录人可管理的部门校验AND s.dept_id #{deptId} AND EXISTS ( SELECT 1 FROM dept_manager dm WHERE dm.emp_no #{loginEmpNo} AND dm.dept_id s.dept_id )如果这两个条件只保留一个就会出现接口能查到数据但前端不展示的情况数据仍然泄露。正确的做法是后端直接从登录会话里取 emp_no而不是信任前端传的管理员标识并且对 dept_manager 表建 (emp_no, dept_id) 联合唯一键防止一个主管被重复授权。5.3 离职交接软删除与历史排班保留处理离职员工时不要物理删除 emp 记录否则历史排班表通过 emp_no 关联不到姓名考勤汇总也会丢失人员信息。常见做法是只更新 status 字段并把排班查询统一带上 status 1 条件这样员工一离职立刻从排班界面消失但历史数据完整保留UPDATE emp SET status 0, leave_date CURRENT_DATE WHERE emp_no #{empNo}离职前未履行的未来排班需要单独清理 schedule 表中该员工 shift_date 大于当天的记录否则月底统计时会把离职后的排班也算进去。这个清理动作放在同一个事务里执行确保离职状态和未来排班的删除要么一起成功要么一起失败。权限配置里还要把该员工的登录账号禁用具体可以在登录查询 emp 表时增加 status 校验status 为 0 直接拒绝登录这样即使手机号没变也无法继续使用系统。本文还有配套的精品资源点击获取
酒店员工管理系统自研实践：排班考勤与数据库设计
简介一份针对酒店员工管理系统的计算机专业毕业论文设计文档适合计算机相关专业学生参考选题、结构撰写与系统开发实现。内容围绕SSM框架、MySQL数据库、HTML及B/S架构展开完整覆盖课题背景、可行性分析、系统流程图、用例图、数据库设计、界面实现和系统测试等章节并提供了管理员、普通管理员、员工三种角色的权限划分与功能模块说明对毕业设计或课程项目的落地具有较强的参考价值。资源为1个docx文档大小约970KB包含论文全文共32页目录结构清晰便于直接查阅和续写。目前已吸引201人浏览学习适合需要快速搭建毕设框架或借鉴论文格式与设计思路的读者。1. 酒店员工管理系统为什么值得自研而不是采购通用人事 SaaS酒店一线员工的排班规则远比写字楼里的固定工时复杂客房部按当天退房清房量安排班次餐饮部同时排早中晚三班前台经常需要跨零点换班。通用人事软件把排班考勤收敛在“固定上下班时间 加班审批”这套模型里到了酒店场景就出现班次结束时间早于开始时间、月度工时浮动、换班需多人确认等兼容成本。与其年年付定制开发费用不如按酒店的真实流程做一套员工管理系统把排班、打卡、考勤汇总和人员状态放进同一个数据库。这篇内容要做的就是从一个可落地的设计和实现出发先讲清楚数据库表怎么设计再给出后端接口写法、前端操作界面最后落到上线前必须处理的冲突检测、权限和离职交接问题。2. 数据库模型设计员工档案、排班、考勤三张表的约束关系决定一个酒店员工管理系统的开发成本通常先看数据模型。人、某一天、某个时间段这三类信息如果混在一张表里后期加需求时往往要重构。常见做法是拆成三张核心表员工表存相对静态的档案排班表描述未来某个员工在哪个时间段应该在岗考勤表记录实际的打卡结果。下面是这套设计的建表 SQL 和字段取舍。2.1 员工表员工工号与部门关联的取舍CREATE TABLE emp ( emp_no VARCHAR(20) NOT NULL COMMENT 员工工号全局唯一, emp_name VARCHAR(50) NOT NULL COMMENT 员工姓名, dept_id INT NOT NULL COMMENT 部门ID关联dept表, position VARCHAR(30) NULL COMMENT 岗位前台/客房/餐饮/工程, phone VARCHAR(15) NULL COMMENT 手机号用于登录和通知, hire_date DATE NULL COMMENT 入职日期, status TINYINT NOT NULL DEFAULT 1 COMMENT 1在职 0离职, PRIMARY KEY (emp_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;员工表的主键建议直接用员工工号不使用自增 ID。酒店行业里员工工号本身就有业务含义比如前台以 Q 开头、客房以 K 开头并且员工离职后工号会被回收给后续入职的人。如果使用自增主键回收工号会导致历史和未来数据关联混乱。dept_id 单独存不要直接写“客房部”这样的字符串因为部门改名字时只需要改部门表一行记录。2.2 排班表用 shift_date 加 start_time/end_time 表达跨天班次CREATE TABLE schedule ( id BIGINT NOT NULL AUTO_INCREMENT, emp_no VARCHAR(20) NOT NULL COMMENT 关联emp.emp_no, dept_id INT NOT NULL COMMENT 冗余部门ID按部门快速过滤, shift_date DATE NOT NULL COMMENT 班次日期, start_time TIME NOT NULL COMMENT 上班时刻, end_time TIME NOT NULL COMMENT 下班时刻允许小于start_time表示跨天, shift_type VARCHAR(10) NULL COMMENT 早班/中班/夜班, PRIMARY KEY (id), UNIQUE KEY uk_emp_date (emp_no, shift_date), KEY idx_dept_date (dept_id, shift_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;排班表有两个容易踩坑的设计点。第一UNIQUE KEY uk_emp_date限制了同一个员工同一天只能有一条排班这是防重复录入最便宜的手段排班界面后端保存时不用再做一次存在性检查。第二end_time 允许小于 start_time用来表示跨天班次比如前台夜班 22:00 到次日 06:00就存 start_time22:00、end_time06:00。查询展示时前端能直接显示但计算工时或做冲突检测时需要对这种记录单独处理后面第 5 章会给出具体做法。dept_id 冗余在这里是为了避免每次按部门查排班都要先关联员工表再取部门。2.3 考勤表打卡记录的幂等约束CREATE TABLE attendance ( id BIGINT NOT NULL AUTO_INCREMENT, emp_no VARCHAR(20) NOT NULL COMMENT 关联emp.emp_no, work_date DATE NOT NULL COMMENT 出勤日期以排班shift_date为准, clock_in DATETIME NULL COMMENT 实际上班打卡时间, clock_out DATETIME NULL COMMENT 实际下班打卡时间, is_late TINYINT NOT NULL DEFAULT 0 COMMENT 1迟到, is_early TINYINT NOT NULL DEFAULT 0 COMMENT 1早退, source VARCHAR(10) NULL COMMENT 打卡来源ipad/手机/门禁, PRIMARY KEY (id), UNIQUE KEY uk_emp_workdate (emp_no, work_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;考勤表的唯一键是 (emp_no, work_date)一个员工同一天只能有一条考勤汇总。实际打卡时如果已经存在记录就更新 clock_in 或 clock_out而不是再插入一行否则月度统计时同一个人的迟到次数会被重复累计。work_date 使用排班表中的 shift_date而不是自然日。原因在于跨天班次夜班员工 22:00 上班、次日 06:00 下班两次打卡跨了两个自然日但如果按自然日拆分一次班次就会被拆成两条考勤记录统计口径会乱。三张表的约束关系可以汇总成下面这个表用于评审时快速对齐表名唯一键约束目的empemp_no员工身份全局唯一schedule(emp_no, shift_date)一人一天只能有一条排班attendance(emp_no, work_date)一人一天只能一条考勤汇总3. 后端接口设计与实现排班查询、打卡校验与月度汇总后端部分常见实现是 Spring Boot 3.x 配合 MyBatis。选择 Spring Boot 是因为排班、打卡这类接口本质上是少量表的新增和查询它的自动配置能省掉大量模板代码MyBatis 则方便把复杂 SQL 写在 XML 里后续调整统计口径不用重新编译依赖的 service 层。下面按接口拆开讲。3.1 工程结构与依赖按接口划分模块dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId /dependency代码里我习惯按接口组织 controller 和 service而不是按实体类组织。一个排班相关接口对应 ScheduleController、ScheduleMapper一个考勤相关接口对应 AttendanceController、AttendanceService。这样加需求时影响面最小比如“排班增加批量复制上周”只改 Schedule 相关文件不会碰考勤逻辑。Mapper XML 放在 resources/mapper 目录接口和 SQL 分开方便 DBA 评审慢查询时直接打开 XML 看语句。3.2 按部门查询一周排班时间范围参数化RestController RequestMapping(/api/schedule) public class ScheduleController { private final ScheduleMapper scheduleMapper; public ScheduleController(ScheduleMapper scheduleMapper) { this.scheduleMapper scheduleMapper; } GetMapping(/week) public ListScheduleVO week(RequestParam Long deptId, RequestParam String weekStart) { LocalDate start LocalDate.parse(weekStart); LocalDate end start.plusDays(6); return scheduleMapper.selectByDeptAndRange(deptId, start, end); } }select idselectByDeptAndRange resultTypeScheduleVO SELECT s.emp_no, e.emp_name, s.dept_id, s.shift_date, s.start_time, s.end_time, s.shift_type FROM schedule s JOIN emp e ON s.emp_no e.emp_no WHERE s.dept_id #{deptId} AND s.shift_date BETWEEN #{start} AND #{end} AND e.status 1 ORDER BY s.shift_date, s.start_time /select这里 weekStart 由前端传周一日期格式固定为 yyyy-MM-dd后端用LocalDate.parse解析再加 6 天得到周日。接口返回的是平铺的排班记录不是组装好的日历结构因为不同门店的排班展示方式不同有的按周表格看有的按人看列表后端只返回原始排班记录由前端决定怎么渲染。SQL 里BETWEEN是闭区间正好覆盖一周七天。JOIN emp 并过滤 status1是为了不把已离职员工的排班展示给排班主管。3.3 打卡校验迟到判定的时间基准来自排班而非固定时刻public Attendance clockIn(String empNo, LocalTime clockTime) { LocalDate today LocalDate.now(); Schedule schedule scheduleMapper.selectByEmpAndDate(empNo, today); if (schedule null) { throw new BizException(今天没有排班不能打卡); } boolean isLate clockTime.isAfter(schedule.getStartTime()); Attendance att attendanceMapper.selectByEmpAndDate(empNo, today); if (att null) { att new Attendance(); att.setEmpNo(empNo); att.setWorkDate(today); att.setClockIn(LocalDateTime.of(today, clockTime)); att.setIsLate(isLate ? 1 : 0); attendanceMapper.insert(att); } else { att.setClockIn(LocalDateTime.of(today, clockTime)); if (isLate) { att.setIsLate(1); } attendanceMapper.update(att); } return att; }这段逻辑的核心是“早退和迟到都是相对于这个员工当天的排班时间来判断的”而不是统一用 9 点作为迟到线否则夜班员工永远会被判迟到。isLate一旦置为 1 就不再清除因为员工发现迟到后重新打卡不应该把迟到覆盖掉这是酒店考勤管理的常见规则。同一个员工一个自然日内的第二次打卡走 update 分支保证 attendance 不会出现重复记录。3.4 月度考勤汇总在 SQL 里聚合而不是在内存里计数select idsummaryMonthly resultTypeAttendanceSummaryVO SELECT emp_no, COUNT(*) AS work_days, SUM(is_late) AS late_days, SUM(is_early) AS early_days, SUM(TIMESTAMPDIFF(MINUTE, clock_in, clock_out)) AS work_minutes FROM attendance WHERE work_date BETWEEN #{startDate} AND #{endDate} GROUP BY emp_no /select月度汇总直接在 SQL 里做聚合而不是把所有考勤记录加载到内存再一层层 for 循环加总。几十个员工的单月记录看起来不多但按年查询或连锁酒店多门店汇总时内存方式会把单次请求的耗时从几十毫秒拉到几秒。注意work_minutes对这个统计方式是基于打卡的实际时间差计算的跨天班次因为 clock_out 是完整的 DATETIME包含日期所以 TIMESTAMPDIFF 结果天然正确真正需要修正跨天问题的是排班冲突检测也就是第 5 章的内容。4. 前端管理界面与交互部门树、排班表格和编辑状态酒店员工管理系统的前端最重要的页面就是“排班管理”。它要同时解决两个问题让排班主管快速看清一周内每个部门的人怎么安排以及让修改班次的操作尽量少点几下鼠标。常见实现是 Vue 3 Element Plus左侧部门树右侧排班表格。4.1 页面结构左侧部门树加右侧排班表格template el-container el-aside width220px el-tree :datadeptTree node-keyid :props{ label: name, children: children } node-clickonSelectDept / /el-aside el-main el-table :datascheduleRows border el-table-column propempName label员工 width100 / el-table-column propshiftDate label日期 width110 / el-table-column propstartTime label上班 width80 / el-table-column propendTime label下班 width80 / el-table-column label班次 width120 template #default{ row } el-select v-modelrow.shiftType sizesmall el-option label早班 value早班 / el-option label中班 value中班 / el-option label夜班 value夜班 / /el-select /template /el-table-column /el-table /el-main /el-container /template部门树的数据结构是{ id, name, children }与后端 dept 表的父子关系对应。排班表格每一行代表一个员工某一天的排班。el-select直接放在表格列里主管点开下拉就能改班次不需要先选中行再点“编辑”按钮。这个交互对高频换班的酒店场景很重要早餐班临时缺人时主管能在 10 秒内改完三四个人的班次。4.2 数据加载调用一周排班接口并对应渲染import { ref, onMounted } from vue const deptId ref(null) const weekStart ref() const scheduleRows ref([]) async function loadWeek() { const params new URLSearchParams({ deptId: deptId.value, weekStart: weekStart.value }) const res await fetch(/api/schedule/week?${params}) if (!res.ok) { throw new Error(加载排班失败) } scheduleRows.value await res.json() } onMounted(() { weekStart.value getMonday(new Date()) loadWeek() })这里的 fetch 调用对应第 3.2 节的排班接口前端把当前选中部门和本周周一日期传给后端。getMonday是一个工具函数把当前日期规整到本周周一。接口返回的每个字段直接映射到表格列后端返回 null 的 end_time 字段表格会显示为空代表这个员工当天没有排班。实际操作中点击左侧部门树节点就重新调一次loadWeek()并把 scheduleRows 清空避免上一个部门的排班残留显示在表格里。给表格加v-loading指令在请求发出期间显示 loading 遮罩防止主管在数据还没回来时误改旧数据。4.3 批量保存编辑后的排班如何提交到后端async function saveRows() { const body scheduleRows.value.map(row ({ empNo: row.empNo, shiftDate: row.shiftDate, startTime: row.startTime, endTime: row.endTime, shiftType: row.shiftType })) const res await fetch(/api/schedule/batch, { method: PUT, headers: { Content-Type: application/json }, body: JSON.stringify(body) }) if (!res.ok) { alert(保存失败请检查是否有重复排班) } }前端不按行提交而是把当前表格所有行做成数组一次提交对应后端批量更新接口。这样做的好处是主管可以连续改多行后统一保存网络请求次数少数据库也能用事务保证这一批排班要么全部成功要么全部失败。后端 batch 接口的常见做法是逐条执行 upsert即存在则更新、不存在则插入然后整体提交事务。前端交互动作与后端接口的对应关系可以整理成一张表新成员接手时看这张表就能定位代码前端动作请求地址方法切换部门/加载一周排班/api/schedule/week?deptIdweekStartGET修改班次下拉框无请求本地暂存-批量保存排班/api/schedule/batchPUT查看员工某月考勤/api/attendance?empNomonthGET5. 上线前必做的三类验证与参数调优系统能跑通不等于能上线。酒店员工管理系统最容易在三个边界出问题排班重叠、越权查看、离职员工的排班残留。这三类问题都和数据写入规则有关放到上线前去验证比事后补数据要轻松得多。5.1 排班重叠检测用分钟化区间处理跨天班次跨天排班让冲突检测不能直接用 TIME 比较否则 22:00 到次日 06:00 和 05:00 到 07:00 会被误判为不重叠。我一般会在接口层把时间转成当天分钟数再比较private boolean isOverlap(Schedule existing, LocalTime newStart, LocalTime newEnd) { int exStart existing.getStartTime().toSecondOfDay() / 60; int exEnd existing.getEndTime().toSecondOfDay() / 60; if (exEnd exStart) { exEnd 1440; } int nStart newStart.toSecondOfDay() / 60; int nEnd newEnd.toSecondOfDay() / 60; if (nEnd nStart) { nEnd 1440; } return nStart exEnd exStart nEnd; }核心思路是把跨天班次的结束时间加上 1440 分钟再判断两个区间是否重叠。这个判断要嵌在批量保存接口里对每个员工的每条新排班与库里已有排班遍历比较发现有重叠就整批回滚并提示是哪一天冲突。5.2 权限边界部门主管接口必须带数据范围参数酒店员工管理系统的排班权限通常按部门隔离客房部主管不应该看到餐饮部的排班。后端查询 SQL 里除了 deptId 还要加一个当前登录人可管理的部门校验AND s.dept_id #{deptId} AND EXISTS ( SELECT 1 FROM dept_manager dm WHERE dm.emp_no #{loginEmpNo} AND dm.dept_id s.dept_id )如果这两个条件只保留一个就会出现接口能查到数据但前端不展示的情况数据仍然泄露。正确的做法是后端直接从登录会话里取 emp_no而不是信任前端传的管理员标识并且对 dept_manager 表建 (emp_no, dept_id) 联合唯一键防止一个主管被重复授权。5.3 离职交接软删除与历史排班保留处理离职员工时不要物理删除 emp 记录否则历史排班表通过 emp_no 关联不到姓名考勤汇总也会丢失人员信息。常见做法是只更新 status 字段并把排班查询统一带上 status 1 条件这样员工一离职立刻从排班界面消失但历史数据完整保留UPDATE emp SET status 0, leave_date CURRENT_DATE WHERE emp_no #{empNo}离职前未履行的未来排班需要单独清理 schedule 表中该员工 shift_date 大于当天的记录否则月底统计时会把离职后的排班也算进去。这个清理动作放在同一个事务里执行确保离职状态和未来排班的删除要么一起成功要么一起失败。权限配置里还要把该员工的登录账号禁用具体可以在登录查询 emp 表时增加 status 校验status 为 0 直接拒绝登录这样即使手机号没变也无法继续使用系统。本文还有配套的精品资源点击获取