简介：这份资源是面向高校计算机相关专业学生的数据库课程设计参考包，聚焦酒店管理系统中的客房管理模块，适合正在完成课程设计、需要理解关系型数据库建模与业务落地的学习者。内容围绕客房、客户、订单、入住与退房记录等实体展开，涉及表结构设计、主外键约束、数据类型分配以及基于SQL的增删改查与前端交互实现，可帮助读者梳理从数据模型到功能测试的完整思路。压缩包共30个文件，以18个class与10个java源码文件为主，另有2张jpg图片，整体约404KB，源码结构便于对照阅读与二次调试。该资源已有1877人学习下载，读者可从中获取客房状态更新、预订入住流程、界面与数据库连接等具体实现参考，并借鉴数据完整性与安全性方面的处理方式，用于课程设计答辩准备与功能扩展。
1. 从一张房态表说起：这个酒店客房管理系统到底能干什么
很多数据库课程设计最后都做成了“能跑就行”的增删改查，答辩时被问一句“退房和换房的事务怎么保证一致”就卡住。这个酒店管理系统（客房管理）走的是另一条路：它把客房当作核心实体，围绕房态流转把入住、换房、退房、预订、清洁状态串成一条完整链路，配套建表脚本、视图、存储过程和触发器，适合拿来做课程设计交付，也适合想练手数据库建模的开发者二次改造。你拿到手能直接看到表结构怎么设计、房态怎么约束、并发下怎么避免重复开房，而不是一堆散落的 SQL 片段。下面按“能干什么、怎么跑、怎么改”的顺序拆开讲。
2. 技术栈与目录结构：一套能直接导入的数据库工程
2.1 技术选型与运行环境
这个项目的定位很明确：数据库课程设计，重心在数据层，不在前端炫技。常见做法是 MySQL 8.0 作为主库，字符集 utf8mb4，存储引擎 InnoDB，靠外键和事务保证客房与订单的一致性；配套一个轻量后端（Java Spring Boot 或 Python Flask 二选一）暴露 REST 接口，前端用简单的 HTML + 原生 JS 或 Vue 起步模板，够演示即可。选 InnoDB 不是玄学，是因为房态变更、订单写入、账单生成这几步必须在一个事务里，MyISAM 没有事务，退房时账单写失败就会留下“房已退、账没记”的黑匣子状态。
运行环境我一般这样配：MySQL 8.0.x、JDK 17（若选 Java）、Node 18（若前端要构建）、Navicat 或 DBeaver 用来跑脚本看结果。版本不用卡太死，MySQL 5.7 也能跑，但 8.0 的窗口函数和 CHECK 约束用起来更顺手，课程设计里写个房态统计视图会省不少事。
2.2 目录结构长什么样
工程目录通常按“数据库脚本 + 后端 + 前端 + 文档”四块分，下面是我拆过的同类项目里最典型的一种布局：
hotel-room-system/ ├── sql/ │ ├── 01_schema.sql # 建库建表、外键、索引 │ ├── 02_view.sql # 房态统计、在住客人等视图 │ ├── 03_procedure.sql # 入住/退房/换房存储过程 │ ├── 04_trigger.sql # 房态联动触发器 │ └── 05_seed.sql # 房型、房间、测试订单初始数据 ├── backend/ │ ├── src/main/java/... # Controller / Service / Mapper │ └── resources/application.yml ├── frontend/ │ ├── index.html # 房态看板 │ └── js/room.js └── docs/ ├── er图说明.md └── 接口文档.md这个结构的好处是脚本按执行顺序编号，新手照着 01 到 05 依次跑就不会因为外键依赖顺序翻车。sql/目录是整个项目的骨架，后端只是把脚本里的能力包成接口，前端只负责把房态画成格子。二次开发时你改得最多的也是sql/和backend里的 Service 层。
2.3 核心表设计：客房、房型、订单、入住记录
客房管理的核心是四张表：房型表定价格和床位，房间表定物理房间和当前房态，订单表定预订与结算，入住记录表定实际住客和起止时间。下面这段建表脚本是项目里最该先看懂的部分：
-- 房型表：一种房型对应多条房间记录 CREATE TABLE room_type ( type_id INT PRIMARY KEY AUTO_INCREMENT, type_name VARCHAR(32) NOT NULL, -- 如"标准双床房" base_price DECIMAL(10,2) NOT NULL, -- 门市价 bed_count TINYINT NOT NULL DEFAULT 1, max_guest TINYINT NOT NULL DEFAULT 2 ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 房间表：房态是客房管理的核心字段 CREATE TABLE room ( room_id INT PRIMARY KEY AUTO_INCREMENT, room_no VARCHAR(8) NOT NULL UNIQUE, -- 如"0801" type_id INT NOT NULL, floor_no TINYINT NOT NULL, status ENUM('空闲','已预订','在住','待清洁','维修') NOT NULL DEFAULT '空闲', CONSTRAINT fk_room_type FOREIGN KEY (type_id) REFERENCES room_type(type_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 订单表：一条订单可对应多间房，这里简化为单房订单 CREATE TABLE booking ( booking_id BIGINT PRIMARY KEY AUTO_INCREMENT, room_id INT NOT NULL, guest_name VARCHAR(32) NOT NULL, guest_phone VARCHAR(20) NOT NULL, check_in DATE NOT NULL, check_out DATE NOT NULL, status ENUM('预订','在住','已退房','已取消') NOT NULL DEFAULT '预订', total_amount DECIMAL(10,2) DEFAULT 0.00, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, CONSTRAINT fk_booking_room FOREIGN KEY (room_id) REFERENCES room(room_id), INDEX idx_room_status (room_id, status) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;逻辑说明：room.status用 ENUM 而不是自由文本，是为了让房态流转有明确边界，避免出现“已退房但状态写成空房”这种脏数据；booking上建(room_id, status)联合索引，是因为查“这间房当前有没有在住订单”是最高频的查询，没索引时房间一多就明显变慢。参数上room_no加 UNIQUE 约束，防止同一房号被重复录入，这是课程设计答辩常被挑的点。total_amount默认 0，实际金额在退房存储过程里按入住天数乘房价算出来回写，不在插入时算，避免预订阶段价格变动导致对不上账。
3. 跑起来：从建库到房态看板能点开
3.1 初始化数据库与导入脚本
第一步永远是建库和跑脚本，顺序不能乱。我一般先确认 MySQL 服务在跑，再用命令行按编号执行：
# 登录 MySQL mysql -u root -p # 建库并指定字符集 CREATE DATABASE hotel_room DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE hotel_room; # 按顺序导入，注意路径换成你本地的 SOURCE /path/to/sql/01_schema.sql; SOURCE /path/to/sql/02_view.sql; SOURCE /path/to/sql/03_procedure.sql; SOURCE /path/to/sql/04_trigger.sql; SOURCE /path/to/sql/05_seed.sql;命令含义：SOURCE是 MySQL 客户端的内置命令，比mysql < file.sql更适合在交互式会话里逐段排查错误。执行完05_seed.sql后，room表里应该有几十条房间记录，房态分布在不同状态，方便你打开看板就能看到效果。如果某一步报外键错误，八成是前一个脚本没跑成功，先回去看 01 的输出，别急着往下灌。
3.2 启动后端与前端
后端启动前先改application.yml里的数据库连接，账号密码换成你本地的：
spring: datasource: url: jdbc:mysql://localhost:3306/hotel_room?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.DriverserverTimezone必须显式指定，否则 MySQL 8 驱动在部分环境下会把日期差出 8 小时，退房日期算错一天，这种问题排查起来很费时间。改完配置后mvn spring-boot:run或python app.py启动，看到端口监听成功即可。前端如果是纯静态页，直接用浏览器打开index.html或起个python -m http.server 8080，把接口地址指向后端端口就能看到房态格子。
3.3 验证核心链路：入住、换房、退房
跑通不等于验证过。我一般按一条完整链路点一遍：选一间空闲房办理入住，看room.status是否变成“在住”、booking是否新增一条“在住”订单；再执行换房，看原房是否变“待清洁”、新房是否变“在住”；最后退房，看订单状态变“已退房”、金额是否按天数算对、房间是否进入“待清洁”。这三步走完，说明存储过程和触发器是通的。下面这段是退房存储过程的核心逻辑，也是整个项目最值得逐行读的部分：
DELIMITER $$ CREATE PROCEDURE sp_checkout(IN p_booking_id BIGINT, OUT p_amount DECIMAL(10,2)) BEGIN DECLARE v_room_id INT; DECLARE v_days INT; DECLARE v_price DECIMAL(10,2); -- 开事务，保证订单、房间、金额三者一致 START TRANSACTION; SELECT b.room_id, DATEDIFF(b.check_out, b.check_in), rt.base_price INTO v_room_id, v_days, v_price FROM booking b JOIN room r ON r.room_id = b.room_id JOIN room_type rt ON rt.type_id = r.type_id WHERE b.booking_id = p_booking_id AND b.status = '在住' FOR UPDATE; -- 行锁，防止并发退同一单 IF v_room_id IS NULL THEN ROLLBACK; SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '订单不存在或状态不允许退房'; END IF; SET p_amount = v_days * v_price; UPDATE booking SET status = '已退房', total_amount = p_amount WHERE booking_id = p_booking_id; UPDATE room SET status = '待清洁' WHERE room_id = v_room_id; COMMIT; END$$ DELIMITER ;逻辑说明：FOR UPDATE是这段的关键，两个前台同时点退房时，后到的会等前一个事务提交，避免同一单被退两次、金额被覆盖。DATEDIFF算天数，参数是退房日期减入住日期，跨月跨年都按自然日算，符合酒店计费习惯。SIGNAL SQLSTATE '45000'是自定义业务异常，后端捕获后返回“订单状态异常”给前端，比直接抛数据库错误友好。p_amount用 OUT 参数回传，调用方CALL sp_checkout(1001, @amt); SELECT @amt;就能拿到金额，不用再查一次表。
4. 核心模块拆解：房态联动与统计视图
4.1 触发器实现房态自动联动
房态最容易出错的地方是“订单变了、房间状态没跟着变”。项目里用触发器把两者绑在一起，入住订单插入时自动把房间置为“在住”，订单取消时把房间放回“空闲”：
DELIMITER $$ CREATE TRIGGER trg_booking_insert AFTER INSERT ON booking FOR EACH ROW BEGIN IF NEW.status = '在住' THEN UPDATE room SET status = '在住' WHERE room_id = NEW.room_id; ELSEIF NEW.status = '预订' THEN UPDATE room SET status = '已预订' WHERE room_id = NEW.room_id; END IF; END$$ CREATE TRIGGER trg_booking_cancel AFTER UPDATE ON booking FOR EACH ROW BEGIN IF NEW.status = '已取消' AND OLD.status <> '已取消' THEN UPDATE room SET status = '空闲' WHERE room_id = NEW.room_id; END IF; END$$ DELIMITER ;逻辑说明：AFTER INSERT而不是BEFORE，是因为要等订单行真正落库后再改房态，避免订单插入失败但房态已被改。OLD.status <> '已取消'这个判断防止重复取消时把已入住的房误置为空闲。触发器适合这种强联动的小逻辑，但别把复杂计费塞进去，触发器里做太多事会让排查变难，这是血泪经验。
4.2 统计视图：一眼看清楼层房态分布
课程设计里加一个视图很加分，答辩时能直接展示“每层空闲几间、在住几间”：
CREATE VIEW v_room_status_summary AS SELECT r.floor_no, COUNT(*) AS total_rooms, SUM(CASE WHEN r.status = '空闲' THEN 1 ELSE 0 END) AS free_cnt, SUM(CASE WHEN r.status = '在住' THEN 1 ELSE 0 END) AS occupied_cnt, SUM(CASE WHEN r.status = '待清洁' THEN 1 ELSE 0 END) AS dirty_cnt FROM room r GROUP BY r.floor_no ORDER BY r.floor_no;逻辑说明：SUM(CASE WHEN ...)是行转列的常见写法，比多次子查询快，也更好读。total_rooms用COUNT(*)统计该层全部房间，三个状态计数相加不一定等于总数，因为还有“已预订”“维修”没列出来，这是故意的，看板只关心主要状态。查询时SELECT * FROM v_room_status_summary;就能拿到楼层汇总，前端直接渲染成表格。
4.3 后端接口与房态查询
后端 Service 层通常只做两件事：调存储过程、查视图。以退房接口为例，Mapper 里这样写：
@Select("CALL sp_checkout(#{bookingId}, @amt)") @Options(statementType = StatementType.CALLABLE) void checkout(@Param("bookingId") Long bookingId); @Select("SELECT @amt") BigDecimal getLastAmount();逻辑说明：@Options(statementType = CALLABLE)告诉 MyBatis 这是存储过程调用，不加会当成普通 SQL 报语法错。@amt是会话级变量，同一连接内有效，所以两次查询必须在同一事务或同一连接里，否则拿不到值。这种写法在课程设计里够用，生产环境更稳妥的是用CallableStatement显式注册 OUT 参数，但作为教学项目，简单直接更重要。
5. 避坑与排查：跑这个项目最容易翻车的几处
5.1 脚本执行顺序错导致外键报错
现象：执行01_schema.sql时报Cannot add foreign key constraint。原因：建表语句里引用了还没创建的表，或者被引用表的字段类型、字符集不一致。解决：严格按 01 到 05 顺序执行，建表时被引用表先建；字符集统一 utf8mb4，room_id在两张表里都必须是 INT，不能一边 INT 一边 BIGINT。
5.2 日期差一天
现象：退房金额算出来比预期少一天或多一天。原因：check_in、check_out用了 DATETIME 且带时分秒，DATEDIFF只取日期部分，但插入时如果带了时间，跨零点就会差。解决：入住退房字段统一用 DATE 类型，前端传参只传yyyy-MM-dd，后端别自作主张补时间。
5.3 并发退房金额被覆盖
现象：两个窗口同时退同一单，金额出现两次不同结果。原因：没加行锁，两个事务都读到了旧状态。解决：存储过程里SELECT ... FOR UPDATE锁住订单行，并在更新前校验status = '在住'，不满足直接回滚。
5.4 触发器递归或重复触发
现象：更新订单状态后房态被改两次，或报Can't update table in stored function/trigger。原因：触发器里又去更新触发它的同一张表，或逻辑没判断新旧状态差异。解决：触发器只操作room表，不碰booking；更新类触发器必须加OLD.status <> NEW.status判断。
5.5 中文乱码
现象：房型名、客人姓名存进去变成问号。原因：建库、建表、连接串三处字符集不一致。解决：建库DEFAULT CHARSET=utf8mb4，连接串加characterEncoding=utf8，Navicat 里也确认连接编码是 utf8mb4，三处对齐就不会乱。
6. 二次开发：把单房订单扩成多房订单的改造思路
课程设计交完不是终点，真正练手的是改造。这个项目最自然的扩展方向是把“一单一房”改成“一单多房”，因为现实里一家人订两间房很常见。改造分三步走，我按自己踩过的顺序说。
第一步改表结构，新增订单明细表，把房间和订单解耦：
CREATE TABLE booking_item ( item_id BIGINT PRIMARY KEY AUTO_INCREMENT, booking_id BIGINT NOT NULL, room_id INT NOT NULL, price DECIMAL(10,2) NOT NULL, CONSTRAINT fk_item_booking FOREIGN KEY (booking_id) REFERENCES booking(booking_id), CONSTRAINT fk_item_room FOREIGN KEY (room_id) REFERENCES room(room_id), UNIQUE KEY uk_room_booking (booking_id, room_id) );booking表里的room_id字段保留但不再作为主关联，历史数据迁移时把原room_id灌进booking_item即可。uk_room_booking唯一键防止同一订单重复加同一间房。
第二步改存储过程，退房时按明细逐间释放房间，金额按明细汇总：
-- 退房时遍历明细，逐间置为待清洁 UPDATE room r JOIN booking_item bi ON bi.room_id = r.room_id SET r.status = '待清洁' WHERE bi.booking_id = p_booking_id; -- 金额改为明细汇总 SELECT SUM(price) INTO p_amount FROM booking_item WHERE booking_id = p_booking_id;第三步改前端房态看板，从“一间房一个格子”改成“一个订单卡片带多间房”，点击卡片展开明细。验证方法很直接：造一个两间房的订单，退房后看两间房是否都变“待清洁”、金额是否等于两间之和、booking_item是否完整保留历史价格。
改造时有个习惯我一直保持：每次动表结构前先把05_seed.sql备份一份，改完用种子数据重跑一遍全链路，确认入住、换房、退房三条路径都没断，再往真实数据上迁。从那以后我每次改数据库脚本都强制走一遍“备份种子数据、重跑、点三条链路”的流程，省下过好几次半夜回滚的麻烦。希望帮到你。
本文还有配套的精品资源，点击获取
