数据库课程设计：宿舍管理系统建模、SQL脚本与事务实现

简介：面向高校数据库课程设计场景的学生宿舍管理系统资料，适合需要完成课程设计、数据库建库与功能实现练习的本科生参考。系统围绕寝室长与宿管员两类角色展开，包含登录身份判断、寝室人员信息查看、报修提交、住宿信息按学号检索与增删、报修状态处理、学生账号管理及密码修改等模块，数据库设计覆盖寝室长、宿管员、报修和学生信息等表单，能帮助读者理解权限划分、表结构设计与业务功能之间的对应关系。压缩包共3个文件，以rar源代码归档、sql建库脚本和docx文档模板为主，整体约2.96MB，便于结合SQL脚本还原数据库并对照文档梳理设计思路。已有5057人学习，可作为课程设计选题、功能拆解、表结构参考与后续二次开发的基础素材。

1. 一次床位核对引出的选题：数据库课程设计为什么选宿舍管理系统

每年开学前两周，宿管科最头疼的事情是核对床位：表格里写着 412 住 4 个人，实际只住了 3 个，还有一份调宿申请压在纸质登记本里没录入。同一份数据被抄在三张表里，谁也不知道哪张是对的——这正是数据库课程设计想考的东西：把现实中的冗余和不一致，用实体、约束和事务收拢成一张能自洽的表网。

这份学生宿舍管理系统课程设计要解决的就是这件事。重点不在做一个好看的界面，而在用一次完整建模，把宿舍楼、房间、床位、学生、入住记录、报修单之间的关系固定下来，让“一个床位在同一时间只能有一个在住学生”这类规则由数据库自己守住，而不是靠管理员记性。它适合正在做数据库课程设计、需要一份能对着改的 SQL 脚本、能直接套用的报告模板和素材的人：建模思路、建表脚本、事务写法、验收口径，一条线走完。

2. 需求与数据建模：从宿舍场景抽象出八张核心表

课程设计最容易失分的地方不是代码跑不起来，而是模型撑不住业务。很多同学拿到题目就直接打开建表界面，想到一个字段加一个字段，最后交上去的表结构自己都说不清为什么这么拆。合理的顺序是先划清角色边界，再把纸质登记本上的每一栏翻译成实体和属性，最后才动手写 DDL。

2.1 角色边界：三类使用者各自能碰到哪些数据

宿舍管理系统的角色通常收敛成三类，多划反而讲不清权限矩阵。学生只关心自己的信息：查本人在住床位、提交报修、登记访客、看历史住宿记录。宿管员是日常操作的主力：办理入住、调宿、退宿，受理报修，录入卫生检查结果，按楼栋查询住宿明细。系统管理员负责基础数据：宿舍楼、房间、床位的增删改，账号分配，以及全楼统计报表。

把这三类角色的动作列成一张二维表，行是角色，列是实体，交叉格写“增删改查”中的哪几种，这张表就是后面权限控制和接口设计的依据。我一般会要求学生在报告里把这张表放在需求分析章节的第一页，因为它能一句话回答答辩时最常见的追问：“这个功能为什么只有管理员能做？”

边界划清之后要明确“不做什么”。退宿结算、水电费分摊、门禁对接这类功能看着相关，但会引入新的实体和外部依赖，课程设计周期内做不完也讲不透，写进“范围外说明”比硬塞进去更显专业。

2.2 实体关系推导：把纸质登记本翻译成 ER 图

从登记本出发是最快的推导方式。一本住宿登记本上通常有这几栏：楼号、房间号、床号、学号、姓名、院系、入住日期、退宿日期、经办人。沿着这几栏追问“一和多”的关系：一栋楼有多个房间，一个房间有多张床位，一张床位在不同时间段可以住过不同的学生，一个学生同一时间只在一张床位上。

这里有个关键判断：床位和学生之间不是简单的一对一，而是通过“入住记录”关联的多对多，并且带时间属性。如果直接把 student_no 塞进 bed 表，学生一旦调宿，历史就没了，统计“本学期换过几次宿舍”这类需求直接做不了。把入住记录独立成表，是这套模型里最值得在报告里写一段设计理由的地方。

报修和访客同理。报修单要能追溯“谁在哪个房间报的、什么时候修的、谁受理的”，访客要能追溯“来看谁、什么时候来、什么时候走”。这些时间戳不是可有可无的装饰字段，而是后面做统计查询和状态流转的抓手。

提示：ER 图里的联系如果带属性（比如入住日期、经办人），就应该独立成表，不要硬挂在某一端。

2.3 字段类型与约束的取舍：为什么床号不用 VARCHAR(20)

字段类型是最容易被扣细节分的地方。学号用CHAR(10)而不是VARCHAR(20)，因为它定长、查询频繁、还要做主键，定长在索引里更紧凑。姓名、院系用VARCHAR，长度按实际场景给足但不要一味给 255，VARCHAR(20)存姓名、VARCHAR(40)存院系，既表达了业务预期，也方便在报告里说明“为什么是这个长度”。

状态类字段有两种常见做法：用ENUM或者用TINYINT加字典表。课程设计里我更倾向ENUM，因为可读性直接体现在查询结果里，SELECT status FROM bed出来就是“空闲 / 在住 / 维修”，演示时不用再解释 0 和 1 分别代表什么。代价是后期加状态要改表结构，但课程设计的生命周期里这个代价可以接受。

日期类型也值得写一段。入住日期用DATE就够，报修时间、访客进出时间用DATETIME更合适，因为要精确到时分。退宿日期允许为NULL，NULL在这里是有业务含义的——“仍然在住”，而不是“不知道”。把这一点讲清楚，比多写十个字段更能体现对NULL语义的理解。

金额相关的字段如果确实要做水电费，一定用DECIMAL(8,2)，别用FLOAT。浮点数累加出来的 0.30000000000000004 会在演示时被老师一眼看到，这是个很典型的翻车点。

2.4 从 ER 到表：八张表的最终清单

模型收敛之后，表清单应该能在一页里列完。下面这套是课程设计里比较稳妥的划分，字段数量控制在每表 5 到 10 个，既能覆盖业务，又不至于让报告里的表结构说明写成一本书。

八张表里，building / room / bed 是基础数据，student / checkin 是核心业务，repair / visitor 是流程数据，admin_user 支撑登录。把这张表放进报告，再配一句“基础数据变动少、业务数据增长快，因此索引策略不同”，整章的说服力就上来了。

3. 数据库落地：建表脚本、约束、视图与统计查询的编写顺序

脚本写得好不好，看两点：能不能从头到尾一次跑通，以及跑完之后数据库自己会不会拒绝脏数据。课程设计的 SQL 文件通常要交给老师逐个执行，顺序错了就会报外键错误，这类问题在演示现场非常难看。

3.1 建表顺序与外键依赖：先有楼才有房间

外键要求被引用的表先存在，所以建表顺序必须和依赖方向一致：building → room → bed → student → checkin → repair → visitor。删除时反过来。脚本开头统一DROP TABLE IF EXISTS，并且按逆序删，这样反复执行不会因为残留数据报错。

-- 01_schema.sql 建表脚本，按依赖顺序执行 DROP TABLE IF EXISTS visitor, repair, checkin, admin_user, student, bed, room, building; CREATE TABLE building ( building_id CHAR(4) NOT NULL COMMENT '楼号，如 B01', building_name VARCHAR(30) NOT NULL, floor_count TINYINT UNSIGNED NOT NULL DEFAULT 6, gender_limit ENUM('男','女') NOT NULL COMMENT '整楼性别限制', PRIMARY KEY (building_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE room ( room_id INT UNSIGNED NOT NULL AUTO_INCREMENT, building_id CHAR(4) NOT NULL, room_no VARCHAR(10) NOT NULL COMMENT '房间号，如 412', capacity TINYINT UNSIGNED NOT NULL DEFAULT 4 COMMENT '可住人数', PRIMARY KEY (room_id), UNIQUE KEY uk_building_room (building_id, room_no), CONSTRAINT fk_room_building FOREIGN KEY (building_id) REFERENCES building (building_id) ON DELETE RESTRICT ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE bed ( bed_id INT UNSIGNED NOT NULL AUTO_INCREMENT, room_id INT UNSIGNED NOT NULL, bed_no TINYINT UNSIGNED NOT NULL COMMENT '房间内序号 1-4', status ENUM('空闲','在住','维修') NOT NULL DEFAULT '空闲', PRIMARY KEY (bed_id), UNIQUE KEY uk_room_bed (room_id, bed_no), CONSTRAINT fk_bed_room FOREIGN KEY (room_id) REFERENCES room (room_id) ON DELETE RESTRICT ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这段脚本里有两个设计点值得在报告里单独说明。一是uk_building_room这个联合唯一键，它保证同一个楼里不会出现两个 412 房间，这条规则靠应用层查重也能做，但并发下会漏，交给数据库最省心。二是外键用了ON DELETE RESTRICT而不是CASCADE，因为删掉一栋楼就连带删掉所有入住记录，这在真实业务里是不可接受的，RESTRICT让数据库在删除前先拦住你。

字符集统一用utf8mb4，别用utf8。中文姓名里的生僻字、访客登记里可能出现的特殊字符，utf8存不进去，报错信息还很难懂。

3.2 用唯一索引和 CHECK 把业务规则钉进表结构

课程设计里最能拉开差距的一步，是把“一个床位同一时间只能住一个人”这条规则从应用代码挪到数据库里。MySQL 不支持带条件的部分唯一索引，但可以用生成列绕过去：给入住记录加一个“当前有效床位”的生成列，退宿后自动变NULL，NULL不参与唯一约束，问题就解决了。

CREATE TABLE checkin ( checkin_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, student_no CHAR(10) NOT NULL, bed_id INT UNSIGNED NOT NULL, checkin_date DATE NOT NULL, checkout_date DATE NULL COMMENT 'NULL 表示仍在住', operator VARCHAR(20) NOT NULL COMMENT '经办宿管员', -- 在住时取 bed_id，退宿后为 NULL，配合唯一索引实现在住床位不重复 active_bed_id INT UNSIGNED GENERATED ALWAYS AS (IF(checkout_date IS NULL, bed_id, NULL)) STORED, PRIMARY KEY (checkin_id), UNIQUE KEY uk_active_bed (active_bed_id), KEY idx_checkin_student (student_no, checkout_date), KEY idx_checkin_bed (bed_id), CONSTRAINT fk_checkin_student FOREIGN KEY (student_no) REFERENCES student (student_no) ON DELETE RESTRICT, CONSTRAINT fk_checkin_bed FOREIGN KEY (bed_id) REFERENCES bed (bed_id) ON DELETE RESTRICT ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

uk_active_bed是整份脚本里最有含金量的一行。没有它，两个宿管员同时点“分配床位”，就可能给一张床插进两条在住记录，事后对账对到崩溃。有了它，第二条插入会被数据库直接拒绝，应用层只需要把异常翻译成“该床位已被占用”的提示。

idx_checkin_student用的是(student_no, checkout_date)联合索引，而不是只在学号上建单列索引。因为查“某学生当前是否在住”时条件正好是学号相等加上退宿日期为空，联合索引能直接命中。

CHECK 约束在 MySQL 8.0 之后才真正生效，如果目标环境版本不确定，把这类规则写进应用层更稳妥，报告里注明版本差异即可。

3.3 视图与统计查询：把报表跑在数据库里

课程设计要出彩，统计报表是性价比最高的部分。与其在代码里循环拼数字，不如建一个视图把明细拉平，再在视图上做聚合。住宿明细视图把楼、房、床、人四层左连接拉成一张宽表，空床位也能显示出来，这在“查空床”场景下非常关键。

CREATE OR REPLACE VIEW v_dorm_occupancy AS SELECT b.building_id, b.building_name, r.room_no, bd.bed_id, bd.bed_no, bd.status, s.student_no, s.name, s.college, c.checkin_date FROM bed bd JOIN room r ON r.room_id = bd.room_id JOIN building b ON b.building_id = r.building_id LEFT JOIN checkin c ON c.bed_id = bd.bed_id AND c.checkout_date IS NULL LEFT JOIN student s ON s.student_no = c.student_no; -- 各楼入住率，SUM(条件) 的写法比 CASE WHEN 更短 SELECT building_id, building_name, COUNT(*) AS bed_total, SUM(status = '在住') AS bed_used, ROUND(SUM(status = '在住') / COUNT(*) * 100, 2) AS occupancy_rate FROM v_dorm_occupancy GROUP BY building_id, building_name ORDER BY occupancy_rate DESC;

视图里LEFT JOIN checkin的条件必须带checkout_date IS NULL，否则一个床位住过三个人就会变成三行，入住率算出来超过 100%。这个坑我见过不止一次，答辩时被问“为什么 412 住了 7 个人”会很难解释。

SUM(status = '在住')这种写法依赖 MySQL 把布尔值当 1/0 处理，可读性比SUM(CASE WHEN status='在住' THEN 1 ELSE 0 END)好，但在别的数据库上未必成立，报告里注明“MySQL 方言”就行。

3.4 床位分配的事务与存储过程写法

分配床位要改两张表：往入住记录插一条，把床位状态改成在住。这两步必须在一个事务里，中间失败要能回滚，否则会出现“床显示在住但没人”的孤儿数据。

-- 分配床位：先锁床位行，再插入记录并更新状态 START TRANSACTION; SELECT status FROM bed WHERE bed_id = 12 FOR UPDATE; -- 应用层判断：若 status 不是 '空闲'，此处执行 ROLLBACK INSERT INTO checkin (student_no, bed_id, checkin_date, operator) VALUES ('2023010142', 12, CURDATE(), '宿管A'); UPDATE bed SET status = '在住' WHERE bed_id = 12; COMMIT;

FOR UPDATE是这段代码的核心，它给目标床位加行级排他锁，第二个并发请求会在这里排队等，等第一个事务提交后读到status='在住'，直接被应用层拦下。没有这一行，两个事务可能同时读到“空闲”，然后都插入成功——唯一索引能兜住，但报出来的是数据库异常，不如提前拦住体验好。

如果课程设计要求写存储过程，把上面这段包成sp_assign_bed(IN p_student_no CHAR(10), IN p_bed_id INT, IN p_operator VARCHAR(20))，用DECLARE EXIT HANDLER FOR SQLEXCEPTION做回滚，答辩时能多讲两分钟异常处理。

3.5 初始化数据脚本：让演示一打开就有内容

很多课程设计的数据库交上去是空的，老师打开一看零条记录，印象分直接掉。初始化脚本不用多，但要覆盖典型场景：两栋楼、每栋若干房间、房间满员和有空床两种情况、一个已退宿的历史记录、两条不同状态的报修单。

-- 02_init_data.sql 演示数据，覆盖满员/空床/历史记录三种情况 INSERT INTO building VALUES ('B01', '一号楼', 6, '男'), ('B02', '二号楼', 5, '女'); INSERT INTO room (building_id, room_no, capacity) VALUES ('B01', '101', 4), ('B01', '102', 4), ('B02', '201', 4); INSERT INTO bed (room_id, bed_no, status) VALUES (1, 1, '在住'), (1, 2, '在住'), (1, 3, '空闲'), (1, 4, '维修'); INSERT INTO student VALUES ('2023010142', '甲同学', '男', '信息学院', '13800000001'), ('2023010143', '乙同学', '男', '信息学院', '13800000002'); -- 一条在住、一条已退宿，用来演示“历史可追溯” INSERT INTO checkin (student_no, bed_id, checkin_date, checkout_date, operator) VALUES ('2023010142', 1, '2024-09-01', NULL, '宿管A'), ('2023010143', 1, '2023-09-01', '2024-06-30', '宿管A');

注意最后两条记录都指向bed_id = 1，一条在住一条已退宿。这正是生成列唯一索引要表达的业务：同一张床在不同时间段可以住不同的人，但不能同时住两个人。演示时点开这张表讲一句，比念十页 PPT 都管用。

4. 功能实现：从登录到报修的五条主链路

课程设计的源代码部分最容易写成流水账：一个功能一个函数，谁调谁全靠注释。真正好交付的代码，目录结构能一眼看出分层，核心链路上有事务、有校验、有异常处理，其余边缘功能可以简，但主干不能糊。

4.1 三层结构与目录组织：代码放哪儿才不乱

不管用什么语言，分层的思路是一致的：界面层只负责收集参数和展示结果，业务层做校验和事务编排，数据访问层只跟 SQL 打交道。这样换前端不用动 SQL，换数据库主要改数据访问层。目录按这个思路切，答辩时打开 IDE 就能讲。

dorm-system/ ├── app.py # 入口，路由注册 ├── config.py # 数据库连接参数、会话密钥 ├── dao/ # 数据访问层，一个实体一个文件 │ ├── bed_dao.py │ ├── checkin_dao.py │ └── repair_dao.py ├── service/ # 业务层，放事务和规则校验 │ ├── checkin_service.py │ └── repair_service.py ├── static/ # 样式与脚本 ├── templates/ # 页面模板 └── sql/ ├── 01_schema.sql ├── 02_init_data.sql └── 03_views.sql

sql/目录单独放，且脚本按编号命名，是为了别人拿到源码后知道执行顺序。这一点在报告里写一句“脚本编号即执行顺序”，能省掉老师踩坑的时间，也显得做事有条理。

用 Flask 加 PyMySQL 的组合讲实现比较省事，代码短、依赖少、原理透明。如果原本是 Java Web 或 WinForm 版本，SQL 部分完全通用，把数据访问层换成 JDBC 或 ADO.NET 即可，分层结构不用动。

4.2 登录与权限：密码不能明文落库

课程设计里明文存密码是高频扣分点，而且改起来成本极低。用pbkdf2_hmac加盐哈希，二十行以内搞定，报告里还能补一句“为什么不用 MD5”——MD5 无盐、可彩虹表、已被证明不适合口令存储。

import hashlib, os, hmac def hash_password(raw: str) -> tuple[str, str]: """返回 (salt_hex, hash_hex)，salt 随机 16 字节，迭代 10 万次""" salt = os.urandom(16) digest = hashlib.pbkdf2_hmac("sha256", raw.encode("utf-8"), salt, 100_000) return salt.hex(), digest.hex() def verify_password(raw: str, salt_hex: str, hash_hex: str) -> bool: """用同一 salt 重算并做恒定时间比较，避免时序侧信道""" digest = hashlib.pbkdf2_hmac("sha256", raw.encode("utf-8"), bytes.fromhex(salt_hex), 100_000) return hmac.compare_digest(digest.hex(), hash_hex)

admin_user表里存password_hash和salt两个字段，登录时先按用户名查出这两列，再调verify_password。比较用hmac.compare_digest而不是==，这个细节写进报告是加分项。

权限控制用会话里存role的方式最直观：进入路由前判断角色，学生只能访问/my/*，宿管员能访问/manage/*，管理员才有/admin/*。别在页面上做隐藏按钮就当权限做完了，后端必须再判一次。

4.3 入住与调宿：一个事务里要改几张表

入住要改两张表，调宿要改三张：旧床位状态回空闲、旧入住记录填退宿日期、新床位状态改在住、插入新入住记录。四步操作在一个事务里，任何一步失败全回滚。

def transfer_bed(conn, student_no: str, new_bed_id: int, operator: str): """调宿：退旧床、占新床，四步操作放在同一事务内""" with conn.cursor() as cur: try: conn.begin() # 1. 找到该学生当前在住的记录，并锁住旧床位 cur.execute(""" SELECT checkin_id, bed_id FROM checkin WHERE student_no = %s AND checkout_date IS NULL FOR UPDATE """, (student_no,)) old = cur.fetchone() if old is None: raise ValueError("该学生当前没有在住记录") # 2. 确认新床位空闲，并加锁防止并发抢占 cur.execute("SELECT status FROM bed WHERE bed_id = %s FOR UPDATE", (new_bed_id,)) if cur.fetchone()["status"] != "空闲": raise ValueError("目标床位不可用") # 3. 结旧账：填退宿日期、旧床位置空闲 cur.execute("UPDATE checkin SET checkout_date = CURDATE() " "WHERE checkin_id = %s", (old["checkin_id"],)) cur.execute("UPDATE bed SET status = '空闲' WHERE bed_id = %s", (old["bed_id"],)) # 4. 开新账：插新记录、新床位置在住 cur.execute("INSERT INTO checkin (student_no, bed_id, checkin_date, operator) " "VALUES (%s, %s, CURDATE(), %s)", (student_no, new_bed_id, operator)) cur.execute("UPDATE bed SET status = '在住' WHERE bed_id = %s", (new_bed_id,)) conn.commit() except Exception: conn.rollback() # 任何一步失败都回到调宿前的状态 raise

这段代码有两个参数值得在报告里解释：FOR UPDATE出现两次，锁的是旧记录和新床位两处，避免两个学生互相调宿时死锁——实践里按bed_id升序加锁可以进一步降低死锁概率。conn.rollback()放在except里而不是finally，是因为提交成功后再回滚会报错。

调宿是最能体现数据库功底的功能，因为它天然跨多表、天然有并发、天然需要原子性。答辩时主动讲这一段，比被动等着被问强得多。

4.4 报修与访客登记：状态机怎么落到字段上

报修单的status是典型的有限状态机：待受理 → 处理中 → 已完成，任何一步都可以转成已撤销。状态流转要在业务层做校验，不能允许从“已完成”跳回“待受理”。

ALLOWED = { "待受理": {"处理中", "已撤销"}, "处理中": {"已完成", "已撤销"}, "已完成": set(), "已撤销": set(), } def change_repair_status(conn, repair_id: int, target: str): """状态机校验，非法跳转直接拒绝，避免报表统计出错""" with conn.cursor() as cur: cur.execute("SELECT status FROM repair WHERE repair_id = %s", (repair_id,)) row = cur.fetchone() if row is None: raise ValueError("报修单不存在") if target not in ALLOWED[row["status"]]: raise ValueError(f"不允许从 {row['status']} 变更为 {target}") # 完成时补上完成时间，用于统计平均维修时长 cur.execute("UPDATE repair SET status = %s, " "finish_time = IF(%s = '已完成', NOW(), finish_time) " "WHERE repair_id = %s", (target, target, repair_id)) conn.commit()

ALLOWED这个字典就是状态机的全部定义，比散落在各处的if好维护，也方便直接搬进报告当流程图说明。finish_time用IF()条件赋值，避免为“已完成”单独写一条 SQL。

访客登记相对简单，重点是leave_time允许为NULL，查“当前在楼访客”时用leave_time IS NULL过滤。这条查询在演示时很有画面感，可以顺手展示一次。

4.5 查询与分页：宿舍住宿明细怎么一次查出来

列表页要同时支持按楼栋、房间号、是否在住筛选，还要分页。用动态拼条件时，占位符必须走参数绑定，绝不能字符串拼接，这是 SQL 注入的唯一防线。

def search_occupancy(conn, building_id=None, keyword=None, only_free=False, page=1, size=20): """住宿明细查询：条件可选、参数绑定、按需分页""" sql = ["SELECT * FROM v_dorm_occupancy WHERE 1=1"] args = [] if building_id: sql.append("AND building_id = %s") args.append(building_id) if keyword: sql.append("AND (room_no LIKE %s OR name LIKE %s)") args += [f"%{keyword}%", f"%{keyword}%"] if only_free: sql.append("AND status = '空闲'") sql.append("ORDER BY building_id, room_no, bed_no LIMIT %s OFFSET %s") args += [size, (page - 1) * size] with conn.cursor() as cur: cur.execute(" ".join(sql), args) return cur.fetchall()

条件拼接只拼 SQL 片段，值一律走args，这是安全与灵活之间的平衡点。LIMIT ... OFFSET在数据量小时够用，报告里可以补一句“数据量大时改用游标分页”，体现你知道边界在哪。

5. 避坑与排查：课程设计里最容易翻车的五个地方

这些问题几乎每年都会在某些同学身上重演，而且大多不是能力问题，是顺序和习惯问题。提前知道，能省下整晚的调试时间。

5.1 建模建表阶段的三个坑

现象：床位状态和学生入住记录对不上，页面显示床位在住，但查不到住的是谁。原因是在bed表里单独存了status，同时又是靠checkin表判断在住，两份数据各写各的，某次操作只更新了一边。解决方式是把checkin作为唯一事实来源，bed.status只在事务里跟着改，并且写一条对账 SQL 定期跑：找出status='在住'却没有有效入住记录的床位，把它修回空闲。对账 SQL 不长，但能在答辩前救你一命。

现象：插入房间时报 “Cannot add or update a child row”，脚本跑到一半停住。原因是建表和插数据的顺序与依赖方向不一致，或者楼号写错了一个字符。解决办法是严格按 building → room → bed 的顺序执行，初始化数据脚本里对楼号用变量或注释标清楚，执行前先SELECT * FROM building确认一遍。

现象：入住率统计算出来 133%，老师当场问“一栋楼住了多少人”。原因是视图里连接入住记录时没加checkout_date IS NULL，一个床位的历史记录被算成了多行。修法是在LEFT JOIN的ON条件里补上这个过滤，而不是放到WHERE里——放WHERE会把空床位也过滤掉，结果又变成另一个错误。

5.2 代码联调阶段的两个坑

现象：调宿功能在演示时偶尔出现两个学生住同一张床。原因是事务里没有加行锁，两个并发请求都读到“空闲”然后都插入。唯一的生成列索引能兜住数据，但报出来是数据库异常，前台提示很难看。解决方式是在读取目标床位时加FOR UPDATE，把判断和写入放进同一个锁区间内。

现象：本地跑得好好的，换台机器连不上数据库，或者中文全是问号。原因通常是连接串没指定字符集，或者目标机器的 MySQL 版本低于 5.7，不支持生成列。解决办法是在连接参数里显式写charset='utf8mb4'，并在报告的“运行环境”一节写清最低版本要求，顺带准备一份不带生成列的降级脚本，用触发器实现同样的约束。

注意：答辩前一天务必在干净环境里从零执行一遍三个脚本，确认没有依赖你本地的残留数据。

6. 验收与答辩：报告怎么写、演示怎么走、问题怎么答

课程设计的最终交付不是代码，是“老师能在十分钟内相信这套东西是真的”。报告结构和演示路线都应该围绕这个目标排。

报告章节按这个顺序排最稳：需求分析（含角色权限表）、概念设计（ER 图）、逻辑设计（表结构表格，含字段类型、约束、索引说明）、物理实现（建表脚本与关键 SQL）、功能实现（模块划分与核心代码）、测试与运行结果（截图配上输入输出）、问题与改进。字数分配上，逻辑设计和物理实现这两章要占四成以上，因为这是“数据库课程设计”的评分重心，界面截图堆得再多也补不回来。现成的报告模板可以直接拿来改，但表结构表格必须自己填，字段说明那一列写不出内容，说明你还没想清楚。

演示走一条固定路线，三分钟讲完：登录管理员 → 看楼栋房间床位列表 → 办理一次入住（展示床位状态变化）→ 做一次调宿（展示旧记录被填上退宿日期）→ 打开报修单改状态 → 最后切到统计页看入住率。这条路线覆盖了增删改查、事务、状态机、聚合查询四类考点，每一步都能对应到报告里的某一章。

答辩问题基本围着几个固定点转：为什么入住记录要单独建表、为什么外键用 RESTRICT 不用 CASCADE、并发调宿怎么防、NULL在退宿日期里代表什么、索引建在哪几列上、如果楼的规模扩大十倍哪里会先扛不住。前五个答案都在前面的设计里，最后一个可以答“统计查询会先慢，届时把视图物化成汇总表按天刷新”。

有个习惯我一直在用：交之前把数据库导出成一份干净的.sql，在另一台机器上导入、跑一遍演示路线，全程不碰自己电脑。有一次就是靠这一步发现初始化脚本里少插了一栋楼，导致统计页只有一行数据。从那以后我每次交付前都强制走一遍“干净环境重放”，再留一份带截图的验收清单。希望帮到你。

本文还有配套的精品资源，点击获取