简介这是一份数据库课程设计报告主题为酒店客房信息管理系统适合数据库原理及应用课程的学生参考帮助掌握数据库设计全流程与SQL实践。报告围绕系统开发展开涵盖设计目的、需求分析、系统功能描述、E-R图、数据流图、关系模式设计、物理结构设计以及各数据库表的建立和功能实现代码并附有系统功能评价、设计体会和参考文献。附录中收录登录、系统主界面、个人与团体预订、入住、结账、房客与客房查询、人员与客房管理、报表查询等13个功能模块的核心代码能够为读者提供从需求分析到编码实现的完整参考。资源为单个doc文档大小约760KB内容结构完整、目录清晰便于直接查阅。目前已有1592人学习适合需要完成类似课程设计或准备数据库实践考核的学生使用。1. 数据库课程设计报告-酒店客房信息管理系统建库只是开始拿到“数据库课程设计报告-酒店客房信息管理系统.doc”这个标题很多人第一反应是“不就是写个文档交差吗”。但真正做过一遍的人会告诉你这个题目是典型的“看着简单做起来全是坑”客房状态要流转订单要防重复预订房价要跟日期挂钩退房还要算明细。它比学生管理系统多一个维度——数据会随业务状态变化而改动这正是数据库设计和SQL能力的分水岭。这篇讲的是从零跑通一套酒店客房信息管理系统的完整路径涵盖建表、增删改查、事务控制、统计报表以及报告文档怎么组织才有说服力。适合正在做课程设计、想补全项目短板、或准备数据库面试的读者。不绕弯子直接上结构和代码。2. 表怎么建从客房到订单的实体梳理关键在状态2.1 先拆业务酒店系统里有哪几个数据实体酒店客房信息管理系统的核心业务流是“房态流转”空房 → 已预订 → 已入住 → 已退房中间穿插客户信息、房价、结算。按这个流梳理出至少六张核心表表名用途关键字段room_type房型定义大床/标间/套房type_id, name, base_priceroom物理客房room_id, room_no, type_id, floor, statuscustomer客户基础信息customer_id, name, id_card, phonereservation预订单reserve_id, room_id, customer_id, check_in_date, check_out_date, statuscheck_in入住单对接预订或直接开房checkin_id, room_id, customer_id, ...settle结算记录settle_id, checkin_id, amount, pay_method这个拆分遵循第三范式房型和房间分开因为“房价”属于房型而不是具体房间预订和入住分开因为可以“预订了但没入住”。但要注意课程设计报告不能只交表名得画一张E-R 图标出实体之间的关系基数——每个房型可对应 N 个房间每个客户可有 N 个预订这是后面报告里最值钱的图。2.2 落地 MySQL DDL字段类型怎么选是门学问用 MySQL 8.0 执行下面的建表脚本这是最小可运行版本CREATE DATABASE hotel_db DEFAULT CHARACTER SET utf8mb4; USE hotel_db; CREATE TABLE room_type ( type_id INT AUTO_INCREMENT PRIMARY KEY, type_name VARCHAR(32) NOT NULL COMMENT 房型名称, base_price DECIMAL(10,2) NOT NULL COMMENT 门市价, max_occupancy TINYINT NOT NULL DEFAULT 2 COMMENT 最多入住人数 ); CREATE TABLE room ( room_id INT AUTO_INCREMENT PRIMARY KEY, room_no VARCHAR(8) NOT NULL UNIQUE COMMENT 房间门牌号, floor INT NOT NULL, type_id INT NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0-空房 1-已预订 2-已入住 3-打扫中, CONSTRAINT fk_room_type FOREIGN KEY (type_id) REFERENCES room_type(type_id) ); CREATE TABLE customer ( customer_id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(32) NOT NULL, id_card CHAR(18) NOT NULL UNIQUE, phone VARCHAR(20) ); CREATE TABLE reservation ( reserve_id INT AUTO_INCREMENT PRIMARY KEY, room_id INT NOT NULL, customer_id INT NOT NULL, check_in_date DATE NOT NULL, check_out_date DATE NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0-预订中 1-已入住 2-已取消 3-已过期, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, CONSTRAINT fk_res_room FOREIGN KEY (room_id) REFERENCES room(room_id), CONSTRAINT fk_res_cust FOREIGN KEY (customer_id) REFERENCES customer(customer_id), CONSTRAINT chk_date CHECK (check_out_date check_in_date) );这段代码有几个值得写进报告的点DECIMAL(10,2)存金额而不是 FLOAT避免浮点精度误差CHAR(18)存身份证号因为是定长数字字母组合字段注释 COMMENT必须写数据字典就是从注释批量生成的CHECK 约束MySQL 8.0 才真正生效。外键能不能建要看业务如果允许“无预订直接开房”reservation 的 room_id 就不能设为 NOT NULL 外键这是设计时要想清楚的边界条件。2.3 状态字段别用字符串用 TINYINT 字典表房间状态是用VARCHAR存“空闲”“已住”还是用TINYINT存 0/1/2课程设计里推荐双管齐下数据库存 TINYINT应用层用枚举解释报告里配一张字典说明表。原因有两点一是字符串比较慢、容易打错字二是扩展状态加“维修中”时数值加一条枚举即可不用改表数据。这是 MySQL 数据库设计里非常常见的考察点也是答辩时老师大概率会问的“状态硬编码还是字典表”3. 数据操作层JDBC 连接、预编译和增删改查的完整闭环3.1 配置文件与连接池连接不是 new 就完事课程设计最常见的错误是每次操作都DriverManager.getConnection()用完整导入导出后就卡死在连接上。项目里应当用连接池这是数据库课程设计报告和面试的隐藏得分点。这里先给一个 HikariCP 的最小配置HikariConfig config new HikariConfig(); config.setJdbcUrl(jdbc:mysql://localhost:3306/hotel_db?useSSLfalseserverTimezoneAsia/Shanghai); config.setUsername(root); config.setPassword(yourpassword); config.setMaximumPoolSize(10); config.setMinimumIdle(2); config.setConnectionTimeout(30000); HikariDataSource dataSource new HikariDataSource(config);// 从连接池拿连接的封装 public class DbUtil { private static final HikariDataSource DS init(); private static HikariDataSource init() { HikariConfig cfg new HikariConfig(); cfg.setPoolName(HotelDbPool); cfg.setMaximumPoolSize(10); cfg.setMinimumIdle(2); cfg.setConnectionTimeout(30000); return new HikariDataSource(cfg); } public static Connection getConn() throws SQLException { return DS.getConnection(); } }配置参数里要重点理解maximumPoolSize。HikariCP 官方文档多年的结论是小连接池优于大连接池瓶颈通常在数据库端而非应用端10 个连接足够覆盖一个单机课设系统的并发。connectionTimeout30000指等不到连接时的最大等待时间不是连接创建后的存活时间。这些写进报告会被认为真正用过连接池而不是凑篇幅。3.2 客房登记入住预编译 事务的典型场景登记入住是酒店系统的核心操作涉及三步插入入住单、把房间状态改为“已入住”、把预订状态改为“已入住”。这三步要同时成功或同时失败必须放在一个事务里public boolean checkIn(int roomId, int customerId, Integer reserveId) { String addCheckin INSERT INTO check_in (room_id, customer_id, check_in_time) VALUES (?,?, NOW()); String updateRoom UPDATE room SET status 2 WHERE room_id ? AND status IN (0,1); String updateReserve UPDATE reservation SET status 1 WHERE reserve_id ? AND status 0; try (Connection conn DbUtil.getConn()) { conn.setAutoCommit(false); // 关闭自动提交开启事务 try (PreparedStatement ps1 conn.prepareStatement(addCheckin)) { ps1.setInt(1, roomId); ps1.setInt(2, customerId); ps1.executeUpdate(); } try (PreparedStatement ps2 conn.prepareStatement(updateRoom)) { ps2.setInt(1, roomId); if (ps2.executeUpdate() 0) throw new SQLException(房间状态不允许入住); } if (reserveId ! null) { try (PreparedStatement ps3 conn.prepareStatement(updateReserve)) { ps3.setInt(1, reserveId); ps3.executeUpdate(); } } conn.commit(); // 全部成功才提交 return true; } catch (SQLException e) { e.printStackTrace(); return false; } }注意conn.setAutoCommit(false)之后必须手动commit()否则数据不会落盘。UPDATE room SET status2 WHERE room_id? AND status IN (0,1)这个写法是乐观锁的一种变体——通过条件限定“只有空房或已预订房间可入住”如果返回 0说明房间已经被住直接抛异常回滚。这是幂等的体现同一请求重复调用也不会把已入住的房间改成入住。3.3 客房查询与状态筛选参数核心的“查房”功能要求前端的下拉选择能筛选“全部/空房/已入住/打扫中”这也是数据库课程设计报告里最常用的增删改查展示。用动态 SQL 实现public ListRoomVO queryRooms(Integer typeId, Integer status) { StringBuilder sql new StringBuilder(); sql.append(SELECT r.room_id, r.room_no, r.floor, r.status, t.type_name, t.base_price ); sql.append(FROM room r JOIN room_type t ON r.type_id t.type_id WHERE 11 ); if (typeId ! null) sql.append( AND r.type_id ?); if (status ! null) sql.append( AND r.status ?); sql.append( ORDER BY r.room_no); try (Connection conn DbUtil.getConn(); PreparedStatement ps conn.prepareStatement(sql.toString())) { int idx 1; if (typeId ! null) ps.setInt(idx, typeId); if (status ! null) ps.setInt(idx, status); try (ResultSet rs ps.executeQuery()) { ListRoomVO list new ArrayList(); while (rs.next()) { RoomVO vo new RoomVO(); vo.setRoomNo(rs.getString(room_no)); vo.setFloor(rs.getInt(floor)); vo.setTypeName(rs.getString(type_name)); vo.setBasePrice(rs.getBigDecimal(base_price)); vo.setStatus(rs.getInt(status)); list.add(vo); } return list; } catch (SQLException e) { throw new RuntimeException(e); } } }WHERE 11是为了拼接 AND 条件时不必判断“是否是第一个条件”在 MyBatis 里就是where标签的手动实现。这个查询的说明要写到报告里JOIN 连接两表避免出现“房型名”冗余ResultSet 关闭顺序和 PreparedStatement 关闭顺序是反的吗实际 try-with-resources 自动处理但不妨碍在文档中解释使用顺序的资源释放原则。4. 统计报表与订单联动SQL 聚合、事务隔离级别和死锁处理4.1 今日入住与收入统计酒店系统必须有“今日营业情况”页这是设计报告的盘点部分也是 SQL 晚级查询的考察点。给定三个业务指标对应三条 SQL-- 今日应到预订还没取消的 SELECT COUNT(*) AS expect_checkin FROM reservation WHERE check_in_date CURDATE() AND status 0; -- 当前在住房间数 SELECT COUNT(*) AS occupied_room FROM room WHERE status 2; -- 今日已结算总额 SELECT SUM(amount) AS today_income FROM settle WHERE DATE(create_time) CURDATE();CURDATE()是 MySQL 的日期函数取当前日期如果 settle 表的数据量大DATE(create_time)会导致索引失效正确做法是create_time CURDATE() AND create_time CURDATE() INTERVAL 1 DAY范围查询。这一点可以作为报告里的索引优化示例。4.2 数据的一致性和并发控制多个“前台”同时办理预订时会出现经典问题——同一间房被两个人同时预订。只靠UPDATE room SET status1是不够的因为 check 是查出来的旧数据。解决方式两个乐观锁在 reservation 表加version INT DEFAULT 0更新时UPDATE reservation SET status1, versionversion1 WHERE reserve_id? AND version?更新行数为 0 说明别人改了。悲观锁事务内SELECT * FROM room WHERE room_id? FOR UPDATE锁定该行直到事务结束。课设推荐乐观锁因为更常见而且在简历/报告中容易讲清楚。数据库死锁在课设里确实罕见但老师喜欢问。最简单的防死锁原则所有事务按相同顺序访问表比如先更新 reservation、再更新 room不交叉。如果面试问“如何查看 MySQL 死锁”答案是SHOW ENGINE INNODB STATUS\G找到LATEST DETECTED DEADLOCK段即可看到冲突 SQL。4.3 连接池与并发压力验证一个能体现深度的验证用 JMeter 或 JDBC 脚本模拟 50 个并发同时订同一间房观察最终沉淀的预订记录数。如果不加事务和乐观锁会出现“相同房间同一日期多条预订成功”。课程设计报告里这个测试结果表很有说服力并发线程数未加锁成功数加锁成功数108150231100411这就是事务隔离和并发控制的实际意义。写报告时把测试环境、测试脚本和结果截图放进去加分明显。5. 课程设计报告怎么写数据字典、E-R 图与答辩防线5.1 文档结构先定骨架如果标题是“数据库课程设计报告-酒店客房信息管理系统.doc”那终稿至少要包含这些部分按这个顺序组织需求分析业务流功能模块概念设计E-R 图六张实体、关系逻辑设计关系模式转换范式分析到 3NF物理设计存储引擎选型、索引策略、字符集实现界面截图带时间戳别用网图核心 SQL 与 JAVA/JDBC 关键代码测试用例与结果重点放并发场景5.2 一张数据字典表格胜过十页描述数据库课程设计答辩时老师不看代码逐行读但一定会翻数据字典。给出可照抄的模板字段名类型约束说明room_idINTPK, AUTO_INCREMENT房间唯一标识room_noVARCHAR(8)UNIQUE NOT NULL房间门牌号statusTINYINTDEFAULT 00空房 1已预订 2已入住 3打扫中type_idINTFK → room_type关联房型这里的关键是“说明”列要详细状态注释写清 0/1/2/3 含义别人拿到这张表可以直接还原库结构不需要看文档正文。数据库同步软件、向量数据库、人大金仓、达梦数据库这类热搜词不必硬凑进正文数据字典的规范通用性可以覆盖到。5.3 答辩必问的三个追问与应对围绕这个标题复试时高频问题集中在三个方向。第一个是**“为什么房间状态用 TINYINT 而不是 ENUM”**。应对思路ENUM 的排序不是按定义顺序而是按索引修改枚举值走 DDL 变更而 TINYINT 的映射在应用层改就完成了并且 JDBC 取出来是普通 int 好处理。第二个是**“预订和入住为什么分成两张表”**。应对思路生命周期不同——预订存在“取消、过期”状态入住的终点是结算一张表会把大量无效状态混在一起统计入住率时需要排除 status 的各种异常分支。第三个是**“房价和房型为什么拆表如果门市价要按淡旺季变化怎么加”**。答案是加 price_policy 表通过 date_range 关联这属于“可扩展设计”的展示。数据库课程设计报告里经常考到的数据库死锁、并发锁、join 含义在这个系统里都能给出例子——join 部分用了INNER JOIN从 room 到 room_type 取名称如果换成LEFT JOIN即便 room_type 配置缺失也能把房间查出来这在排查问题时非常实用。数据库热点还包括 MySQL 数据库访问异常处理、在达梦数据库等国产库上的适配思路、利用 DBX 这类可视化工具连接调试——但课设的主要落点还是 MySQL一句“本系统同时适配 MySQL 8.0”就足够兜住扩展面。最后提一个验收技巧不要只跑通功能把步骤录成 GIF并在文档对应章节标出文件名把建表和初始化 insert 数据写成hotel_db.sql附在源码包中用命令行source hotel_db.sql从头导入验证。这一条实践动作决定了交付物是“能跑的项目”还是“可以看的报告。”本文还有配套的精品资源点击获取
数据库课程设计实战：酒店客房信息管理系统建表与并发控制
简介这是一份数据库课程设计报告主题为酒店客房信息管理系统适合数据库原理及应用课程的学生参考帮助掌握数据库设计全流程与SQL实践。报告围绕系统开发展开涵盖设计目的、需求分析、系统功能描述、E-R图、数据流图、关系模式设计、物理结构设计以及各数据库表的建立和功能实现代码并附有系统功能评价、设计体会和参考文献。附录中收录登录、系统主界面、个人与团体预订、入住、结账、房客与客房查询、人员与客房管理、报表查询等13个功能模块的核心代码能够为读者提供从需求分析到编码实现的完整参考。资源为单个doc文档大小约760KB内容结构完整、目录清晰便于直接查阅。目前已有1592人学习适合需要完成类似课程设计或准备数据库实践考核的学生使用。1. 数据库课程设计报告-酒店客房信息管理系统建库只是开始拿到“数据库课程设计报告-酒店客房信息管理系统.doc”这个标题很多人第一反应是“不就是写个文档交差吗”。但真正做过一遍的人会告诉你这个题目是典型的“看着简单做起来全是坑”客房状态要流转订单要防重复预订房价要跟日期挂钩退房还要算明细。它比学生管理系统多一个维度——数据会随业务状态变化而改动这正是数据库设计和SQL能力的分水岭。这篇讲的是从零跑通一套酒店客房信息管理系统的完整路径涵盖建表、增删改查、事务控制、统计报表以及报告文档怎么组织才有说服力。适合正在做课程设计、想补全项目短板、或准备数据库面试的读者。不绕弯子直接上结构和代码。2. 表怎么建从客房到订单的实体梳理关键在状态2.1 先拆业务酒店系统里有哪几个数据实体酒店客房信息管理系统的核心业务流是“房态流转”空房 → 已预订 → 已入住 → 已退房中间穿插客户信息、房价、结算。按这个流梳理出至少六张核心表表名用途关键字段room_type房型定义大床/标间/套房type_id, name, base_priceroom物理客房room_id, room_no, type_id, floor, statuscustomer客户基础信息customer_id, name, id_card, phonereservation预订单reserve_id, room_id, customer_id, check_in_date, check_out_date, statuscheck_in入住单对接预订或直接开房checkin_id, room_id, customer_id, ...settle结算记录settle_id, checkin_id, amount, pay_method这个拆分遵循第三范式房型和房间分开因为“房价”属于房型而不是具体房间预订和入住分开因为可以“预订了但没入住”。但要注意课程设计报告不能只交表名得画一张E-R 图标出实体之间的关系基数——每个房型可对应 N 个房间每个客户可有 N 个预订这是后面报告里最值钱的图。2.2 落地 MySQL DDL字段类型怎么选是门学问用 MySQL 8.0 执行下面的建表脚本这是最小可运行版本CREATE DATABASE hotel_db DEFAULT CHARACTER SET utf8mb4; USE hotel_db; CREATE TABLE room_type ( type_id INT AUTO_INCREMENT PRIMARY KEY, type_name VARCHAR(32) NOT NULL COMMENT 房型名称, base_price DECIMAL(10,2) NOT NULL COMMENT 门市价, max_occupancy TINYINT NOT NULL DEFAULT 2 COMMENT 最多入住人数 ); CREATE TABLE room ( room_id INT AUTO_INCREMENT PRIMARY KEY, room_no VARCHAR(8) NOT NULL UNIQUE COMMENT 房间门牌号, floor INT NOT NULL, type_id INT NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0-空房 1-已预订 2-已入住 3-打扫中, CONSTRAINT fk_room_type FOREIGN KEY (type_id) REFERENCES room_type(type_id) ); CREATE TABLE customer ( customer_id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(32) NOT NULL, id_card CHAR(18) NOT NULL UNIQUE, phone VARCHAR(20) ); CREATE TABLE reservation ( reserve_id INT AUTO_INCREMENT PRIMARY KEY, room_id INT NOT NULL, customer_id INT NOT NULL, check_in_date DATE NOT NULL, check_out_date DATE NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0-预订中 1-已入住 2-已取消 3-已过期, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, CONSTRAINT fk_res_room FOREIGN KEY (room_id) REFERENCES room(room_id), CONSTRAINT fk_res_cust FOREIGN KEY (customer_id) REFERENCES customer(customer_id), CONSTRAINT chk_date CHECK (check_out_date check_in_date) );这段代码有几个值得写进报告的点DECIMAL(10,2)存金额而不是 FLOAT避免浮点精度误差CHAR(18)存身份证号因为是定长数字字母组合字段注释 COMMENT必须写数据字典就是从注释批量生成的CHECK 约束MySQL 8.0 才真正生效。外键能不能建要看业务如果允许“无预订直接开房”reservation 的 room_id 就不能设为 NOT NULL 外键这是设计时要想清楚的边界条件。2.3 状态字段别用字符串用 TINYINT 字典表房间状态是用VARCHAR存“空闲”“已住”还是用TINYINT存 0/1/2课程设计里推荐双管齐下数据库存 TINYINT应用层用枚举解释报告里配一张字典说明表。原因有两点一是字符串比较慢、容易打错字二是扩展状态加“维修中”时数值加一条枚举即可不用改表数据。这是 MySQL 数据库设计里非常常见的考察点也是答辩时老师大概率会问的“状态硬编码还是字典表”3. 数据操作层JDBC 连接、预编译和增删改查的完整闭环3.1 配置文件与连接池连接不是 new 就完事课程设计最常见的错误是每次操作都DriverManager.getConnection()用完整导入导出后就卡死在连接上。项目里应当用连接池这是数据库课程设计报告和面试的隐藏得分点。这里先给一个 HikariCP 的最小配置HikariConfig config new HikariConfig(); config.setJdbcUrl(jdbc:mysql://localhost:3306/hotel_db?useSSLfalseserverTimezoneAsia/Shanghai); config.setUsername(root); config.setPassword(yourpassword); config.setMaximumPoolSize(10); config.setMinimumIdle(2); config.setConnectionTimeout(30000); HikariDataSource dataSource new HikariDataSource(config);// 从连接池拿连接的封装 public class DbUtil { private static final HikariDataSource DS init(); private static HikariDataSource init() { HikariConfig cfg new HikariConfig(); cfg.setPoolName(HotelDbPool); cfg.setMaximumPoolSize(10); cfg.setMinimumIdle(2); cfg.setConnectionTimeout(30000); return new HikariDataSource(cfg); } public static Connection getConn() throws SQLException { return DS.getConnection(); } }配置参数里要重点理解maximumPoolSize。HikariCP 官方文档多年的结论是小连接池优于大连接池瓶颈通常在数据库端而非应用端10 个连接足够覆盖一个单机课设系统的并发。connectionTimeout30000指等不到连接时的最大等待时间不是连接创建后的存活时间。这些写进报告会被认为真正用过连接池而不是凑篇幅。3.2 客房登记入住预编译 事务的典型场景登记入住是酒店系统的核心操作涉及三步插入入住单、把房间状态改为“已入住”、把预订状态改为“已入住”。这三步要同时成功或同时失败必须放在一个事务里public boolean checkIn(int roomId, int customerId, Integer reserveId) { String addCheckin INSERT INTO check_in (room_id, customer_id, check_in_time) VALUES (?,?, NOW()); String updateRoom UPDATE room SET status 2 WHERE room_id ? AND status IN (0,1); String updateReserve UPDATE reservation SET status 1 WHERE reserve_id ? AND status 0; try (Connection conn DbUtil.getConn()) { conn.setAutoCommit(false); // 关闭自动提交开启事务 try (PreparedStatement ps1 conn.prepareStatement(addCheckin)) { ps1.setInt(1, roomId); ps1.setInt(2, customerId); ps1.executeUpdate(); } try (PreparedStatement ps2 conn.prepareStatement(updateRoom)) { ps2.setInt(1, roomId); if (ps2.executeUpdate() 0) throw new SQLException(房间状态不允许入住); } if (reserveId ! null) { try (PreparedStatement ps3 conn.prepareStatement(updateReserve)) { ps3.setInt(1, reserveId); ps3.executeUpdate(); } } conn.commit(); // 全部成功才提交 return true; } catch (SQLException e) { e.printStackTrace(); return false; } }注意conn.setAutoCommit(false)之后必须手动commit()否则数据不会落盘。UPDATE room SET status2 WHERE room_id? AND status IN (0,1)这个写法是乐观锁的一种变体——通过条件限定“只有空房或已预订房间可入住”如果返回 0说明房间已经被住直接抛异常回滚。这是幂等的体现同一请求重复调用也不会把已入住的房间改成入住。3.3 客房查询与状态筛选参数核心的“查房”功能要求前端的下拉选择能筛选“全部/空房/已入住/打扫中”这也是数据库课程设计报告里最常用的增删改查展示。用动态 SQL 实现public ListRoomVO queryRooms(Integer typeId, Integer status) { StringBuilder sql new StringBuilder(); sql.append(SELECT r.room_id, r.room_no, r.floor, r.status, t.type_name, t.base_price ); sql.append(FROM room r JOIN room_type t ON r.type_id t.type_id WHERE 11 ); if (typeId ! null) sql.append( AND r.type_id ?); if (status ! null) sql.append( AND r.status ?); sql.append( ORDER BY r.room_no); try (Connection conn DbUtil.getConn(); PreparedStatement ps conn.prepareStatement(sql.toString())) { int idx 1; if (typeId ! null) ps.setInt(idx, typeId); if (status ! null) ps.setInt(idx, status); try (ResultSet rs ps.executeQuery()) { ListRoomVO list new ArrayList(); while (rs.next()) { RoomVO vo new RoomVO(); vo.setRoomNo(rs.getString(room_no)); vo.setFloor(rs.getInt(floor)); vo.setTypeName(rs.getString(type_name)); vo.setBasePrice(rs.getBigDecimal(base_price)); vo.setStatus(rs.getInt(status)); list.add(vo); } return list; } catch (SQLException e) { throw new RuntimeException(e); } } }WHERE 11是为了拼接 AND 条件时不必判断“是否是第一个条件”在 MyBatis 里就是where标签的手动实现。这个查询的说明要写到报告里JOIN 连接两表避免出现“房型名”冗余ResultSet 关闭顺序和 PreparedStatement 关闭顺序是反的吗实际 try-with-resources 自动处理但不妨碍在文档中解释使用顺序的资源释放原则。4. 统计报表与订单联动SQL 聚合、事务隔离级别和死锁处理4.1 今日入住与收入统计酒店系统必须有“今日营业情况”页这是设计报告的盘点部分也是 SQL 晚级查询的考察点。给定三个业务指标对应三条 SQL-- 今日应到预订还没取消的 SELECT COUNT(*) AS expect_checkin FROM reservation WHERE check_in_date CURDATE() AND status 0; -- 当前在住房间数 SELECT COUNT(*) AS occupied_room FROM room WHERE status 2; -- 今日已结算总额 SELECT SUM(amount) AS today_income FROM settle WHERE DATE(create_time) CURDATE();CURDATE()是 MySQL 的日期函数取当前日期如果 settle 表的数据量大DATE(create_time)会导致索引失效正确做法是create_time CURDATE() AND create_time CURDATE() INTERVAL 1 DAY范围查询。这一点可以作为报告里的索引优化示例。4.2 数据的一致性和并发控制多个“前台”同时办理预订时会出现经典问题——同一间房被两个人同时预订。只靠UPDATE room SET status1是不够的因为 check 是查出来的旧数据。解决方式两个乐观锁在 reservation 表加version INT DEFAULT 0更新时UPDATE reservation SET status1, versionversion1 WHERE reserve_id? AND version?更新行数为 0 说明别人改了。悲观锁事务内SELECT * FROM room WHERE room_id? FOR UPDATE锁定该行直到事务结束。课设推荐乐观锁因为更常见而且在简历/报告中容易讲清楚。数据库死锁在课设里确实罕见但老师喜欢问。最简单的防死锁原则所有事务按相同顺序访问表比如先更新 reservation、再更新 room不交叉。如果面试问“如何查看 MySQL 死锁”答案是SHOW ENGINE INNODB STATUS\G找到LATEST DETECTED DEADLOCK段即可看到冲突 SQL。4.3 连接池与并发压力验证一个能体现深度的验证用 JMeter 或 JDBC 脚本模拟 50 个并发同时订同一间房观察最终沉淀的预订记录数。如果不加事务和乐观锁会出现“相同房间同一日期多条预订成功”。课程设计报告里这个测试结果表很有说服力并发线程数未加锁成功数加锁成功数108150231100411这就是事务隔离和并发控制的实际意义。写报告时把测试环境、测试脚本和结果截图放进去加分明显。5. 课程设计报告怎么写数据字典、E-R 图与答辩防线5.1 文档结构先定骨架如果标题是“数据库课程设计报告-酒店客房信息管理系统.doc”那终稿至少要包含这些部分按这个顺序组织需求分析业务流功能模块概念设计E-R 图六张实体、关系逻辑设计关系模式转换范式分析到 3NF物理设计存储引擎选型、索引策略、字符集实现界面截图带时间戳别用网图核心 SQL 与 JAVA/JDBC 关键代码测试用例与结果重点放并发场景5.2 一张数据字典表格胜过十页描述数据库课程设计答辩时老师不看代码逐行读但一定会翻数据字典。给出可照抄的模板字段名类型约束说明room_idINTPK, AUTO_INCREMENT房间唯一标识room_noVARCHAR(8)UNIQUE NOT NULL房间门牌号statusTINYINTDEFAULT 00空房 1已预订 2已入住 3打扫中type_idINTFK → room_type关联房型这里的关键是“说明”列要详细状态注释写清 0/1/2/3 含义别人拿到这张表可以直接还原库结构不需要看文档正文。数据库同步软件、向量数据库、人大金仓、达梦数据库这类热搜词不必硬凑进正文数据字典的规范通用性可以覆盖到。5.3 答辩必问的三个追问与应对围绕这个标题复试时高频问题集中在三个方向。第一个是**“为什么房间状态用 TINYINT 而不是 ENUM”**。应对思路ENUM 的排序不是按定义顺序而是按索引修改枚举值走 DDL 变更而 TINYINT 的映射在应用层改就完成了并且 JDBC 取出来是普通 int 好处理。第二个是**“预订和入住为什么分成两张表”**。应对思路生命周期不同——预订存在“取消、过期”状态入住的终点是结算一张表会把大量无效状态混在一起统计入住率时需要排除 status 的各种异常分支。第三个是**“房价和房型为什么拆表如果门市价要按淡旺季变化怎么加”**。答案是加 price_policy 表通过 date_range 关联这属于“可扩展设计”的展示。数据库课程设计报告里经常考到的数据库死锁、并发锁、join 含义在这个系统里都能给出例子——join 部分用了INNER JOIN从 room 到 room_type 取名称如果换成LEFT JOIN即便 room_type 配置缺失也能把房间查出来这在排查问题时非常实用。数据库热点还包括 MySQL 数据库访问异常处理、在达梦数据库等国产库上的适配思路、利用 DBX 这类可视化工具连接调试——但课设的主要落点还是 MySQL一句“本系统同时适配 MySQL 8.0”就足够兜住扩展面。最后提一个验收技巧不要只跑通功能把步骤录成 GIF并在文档对应章节标出文件名把建表和初始化 insert 数据写成hotel_db.sql附在源码包中用命令行source hotel_db.sql从头导入验证。这一条实践动作决定了交付物是“能跑的项目”还是“可以看的报告。”本文还有配套的精品资源点击获取
