简介：这份《医院病房管理系统--数据库课设》面向计算机相关专业学生与数据库初学者，提供一套完整的课程设计参考方案，帮助解决从需求分析到系统落地的全流程问题。资源包共146个文件，约5.04MB，以Java源码与编译后的class文件为主，辅以jpg、png界面截图、xml配置、sql建表脚本及doc设计文档，覆盖病人信息、病房床位、医护人员排班等核心模块，便于对照理解实体关系与表结构设计。内容涉及关系数据库理论、主外键与索引视图、B/S架构下的前后端业务逻辑，以及入院登记、用药管理、费用结算等医院业务流程，同时兼顾权限控制与数据备份等安全考量。目前已有165人学习下载，适合需要完成数据库课设、练习SQL与Java开发或梳理医院业务建模思路的读者参考借鉴。
1. 从一份课设压缩包说起：病房管理系统到底在管什么
如果你正在做数据库课程设计，大概率绕不开“医院病房管理”这个题目。它不像电商系统那样有海量现成模板，也不像图书管理那样逻辑简单到一眼望穿。病房管理的麻烦在于：床位是动态的，病人是流动的，医嘱和护理记录还带时间戳，稍不留神就会写出一个“能跑但经不起推敲”的系统。这份《医院病房管理系统--数据库课设.zip》就是冲着这个场景来的，里面通常包含建表 SQL、后端接口、前端页面和一份课设报告。它适合两类人：一是被课设逼到墙角、需要一份能跑通的参考实现的同学；二是想拿一个真实业务模型练手 SQL 优化和事务控制的开发者。你不需要从零画 ER 图，但得知道每张表为什么这么设计，否则答辩时被问一句“床位状态怎么保证不超卖”就会卡住。
2. 拆开压缩包先看数据库：七张核心表与三个反直觉设计
拿到压缩包别急着启动项目，先把 SQL 文件翻出来。病房管理系统的骨架全在表结构里，表没设计好，后面写再多代码都是补丁摞补丁。我一般会先找schema.sql或init.sql，用SHOW CREATE TABLE把每张表的索引和约束过一遍。这一步花二十分钟，能省掉后面两小时的调试。
2.1 从 ER 图到物理表：病人、床位、医嘱的三角关系
病房管理的核心实体其实就三个：病人、床位、医嘱。但课设里通常还会拆出科室、医生、护士、护理记录，凑成七张左右的表。先看最基础的病人表和床位表怎么关联。
-- 病人表：住院号做主键，避免用自增 ID 暴露业务量 CREATE TABLE patient ( patient_id VARCHAR(20) PRIMARY KEY COMMENT '住院号，业务主键', name VARCHAR(50) NOT NULL, gender TINYINT NOT NULL DEFAULT 0 COMMENT '0未知 1男 2女', id_card VARCHAR(18) UNIQUE COMMENT '身份证号，唯一约束', phone VARCHAR(15), admission_date DATETIME NOT NULL COMMENT '入院时间', status TINYINT NOT NULL DEFAULT 1 COMMENT '1在院 2出院 3转科' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 床位表：床号唯一，状态字段是并发控制的重点 CREATE TABLE bed ( bed_id INT AUTO_INCREMENT PRIMARY KEY, ward_no VARCHAR(10) NOT NULL COMMENT '病房号', bed_no VARCHAR(10) NOT NULL COMMENT '床号', status TINYINT NOT NULL DEFAULT 0 COMMENT '0空闲 1占用 2预留 3维修', patient_id VARCHAR(20) DEFAULT NULL COMMENT '当前占用病人', UNIQUE KEY uk_ward_bed (ward_no, bed_no), FOREIGN KEY (patient_id) REFERENCES patient(patient_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;这两张表的关键在于bed.status和bed.patient_id的联动。很多课设版本只改status不改patient_id，结果查“某病人住哪个床”时查不到。常见做法是在业务层用事务包住“更新床位状态”和“写入病人床位关联”两个操作，要么都成功，要么都回滚。
医嘱表是另一个重头。它通常长这样：
CREATE TABLE medical_order ( order_id BIGINT AUTO_INCREMENT PRIMARY KEY, patient_id VARCHAR(20) NOT NULL, doctor_id VARCHAR(20) NOT NULL, content TEXT NOT NULL COMMENT '医嘱内容', order_type TINYINT NOT NULL COMMENT '1长期 2临时', create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, status TINYINT NOT NULL DEFAULT 1 COMMENT '1执行中 2已停止 3已完成', INDEX idx_patient_time (patient_id, create_time) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;注意idx_patient_time这个联合索引。查房时最常用的查询是“某病人最近三天的医嘱”，没有这个索引，数据量一上来就是全表扫描。课设数据量小感觉不出来，但答辩时老师如果问“怎么优化”，这就是现成答案。
2.2 三个容易写错的字段：床位状态、医嘱时效、软删除
第一个坑是床位状态用枚举还是用整数。有些版本用ENUM('空闲','占用')，看着直观，但加一个“预留”状态就要改表结构。我一般建议用TINYINT加注释，扩展时只改代码不改表。
第二个坑是医嘱的时效性。长期医嘱和临时医嘱的停止逻辑不一样：长期医嘱需要显式停止，临时医嘱执行完就结束。如果只用status字段，不记录stop_time，就没法统计“某段时间内实际执行的医嘱量”。常见做法是加一个stop_time DATETIME DEFAULT NULL，停止时写入时间。
第三个坑是软删除。病人出院后数据不能物理删除，否则历史医嘱和护理记录就断了关联。但很多课设版本直接在patient表加is_deleted，查询时忘了过滤，导致已出院病人还出现在在院列表里。更稳妥的做法是用status字段区分在院、出院、转科，查询时明确指定status = 1。
提示：拿到任何课设 SQL 文件，先执行
SELECT table_name, table_comment FROM information_schema.tables WHERE table_schema = '你的库名'，把表清单和注释拉出来，比逐张表翻更快建立全局观。
2.3 初始化数据怎么造：用存储过程批量生成住院记录
课设演示需要数据，手动插几十条不现实。我一般写一个存储过程批量生成病人和床位占用记录，注意控制随机范围，别造出“一个病人同时占两张床”的脏数据。
DELIMITER $$ CREATE PROCEDURE gen_test_data(IN num INT) BEGIN DECLARE i INT DEFAULT 0; DECLARE v_patient_id VARCHAR(20); DECLARE v_bed_id INT; WHILE i < num DO SET v_patient_id = CONCAT('ZY', LPAD(i, 8, '0')); INSERT INTO patient(patient_id, name, gender, admission_date, status) VALUES (v_patient_id, CONCAT('测试病人', i), FLOOR(1 + RAND() * 2), NOW() - INTERVAL FLOOR(RAND() * 30) DAY, 1); -- 只选空闲床位，避免重复占用 SELECT bed_id INTO v_bed_id FROM bed WHERE status = 0 LIMIT 1; IF v_bed_id IS NOT NULL THEN UPDATE bed SET status = 1, patient_id = v_patient_id WHERE bed_id = v_bed_id; END IF; SET i = i + 1; END WHILE; END$$ DELIMITER ;调用CALL gen_test_data(50)就能造出五十条在院记录。注意SELECT ... INTO那行必须加LIMIT 1，否则子查询返回多行会报错。另外存储过程里不要用ORDER BY RAND()，数据量稍大就慢得离谱。
3. 把后端跑起来：三层架构的接口与事务边界
数据库建好之后，下一步是让后端能读写。课设压缩包里常见的是 Java Spring Boot 或 Python Flask 两种技术栈。不管哪种，核心接口就那几个：病人入院、床位分配、医嘱录入、病人出院。每个接口背后都对应一个事务边界，边界画错了，数据一致性就崩了。
3.1 入院接口：一个事务里做完三件事
病人入院不是简单插一条病人记录。它至少包含：插入病人、占用床位、生成入院记录。这三步必须在一个事务里。
// Spring Boot 示例：入院服务方法 @Transactional(rollbackFor = Exception.class) public void admitPatient(AdmitRequest req) { // 1. 插入病人 Patient patient = new Patient(); patient.setPatientId(req.getPatientId()); patient.setName(req.getName()); patient.setAdmissionDate(new Date()); patient.setStatus(1); patientMapper.insert(patient); // 2. 占用床位：用乐观锁防止并发超卖 int updated = bedMapper.occupyBed(req.getBedId(), req.getPatientId()); if (updated == 0) { throw new BusinessException("床位已被占用"); } // 3. 写入入院记录 AdmissionRecord record = new AdmissionRecord(); record.setPatientId(req.getPatientId()); record.setBedId(req.getBedId()); record.setAdmissionTime(new Date()); admissionRecordMapper.insert(record); }@Transactional注解保证三步要么全成要么全滚。关键是第二步的occupyBed，它的 SQL 必须带条件：
UPDATE bed SET status = 1, patient_id = #{patientId} WHERE bed_id = #{bedId} AND status = 0AND status = 0就是乐观锁。两个请求同时抢一张床，只有一个能更新成功，另一个返回 0 行，业务层抛异常回滚。没有这个条件，两个病人都能“住”进同一张床。
3.2 医嘱录入：时间戳与状态机的配合
医嘱录入接口看起来简单，就是插一条记录。但长期医嘱和临时医嘱的处理逻辑不同，状态机要提前想清楚。
# Flask 示例：医嘱录入 @app.route('/order', methods=['POST']) def create_order(): data = request.get_json() order_type = data['order_type'] # 1长期 2临时 status = 1 # 执行中 # 临时医嘱直接标记为已完成，长期医嘱保持执行中 if order_type == 2: status = 3 cursor.execute( "INSERT INTO medical_order(patient_id, doctor_id, content, order_type, status, create_time) " "VALUES (%s, %s, %s, %s, %s, NOW())", (data['patient_id'], data['doctor_id'], data['content'], order_type, status) ) conn.commit() return {'order_id': cursor.lastrowid}临时医嘱直接置为已完成，长期医嘱保持执行中，停止时再更新status = 2并写入stop_time。这个逻辑不复杂，但很多课设版本把两种医嘱混在一起，查“今日待执行医嘱”时把临时医嘱也查出来，护士执行时就会重复操作。
3.3 出院结算：别在事务里做耗时统计
病人出院时要做费用统计，但统计查询往往很慢。如果把它放在事务里，事务持有锁的时间会拉长，并发一高就锁等待。
public void discharge(String patientId) { // 先做统计，不开启事务 BigDecimal totalCost = costService.calculate(patientId); // 再开事务做状态变更 transactionTemplate.execute(status -> { patientMapper.updateStatus(patientId, 2); // 出院 bedMapper.releaseBed(patientId); dischargeMapper.insert(patientId, totalCost); return null; }); }统计放在事务外，状态变更放在事务内。代价是统计结果可能不是绝对精确的“出院那一刻”的费用，但对于课设场景完全够用。如果非要精确，就在事务内加行锁，但那样吞吐量会掉得厉害。
注意：
releaseBed的 SQL 是UPDATE bed SET status = 0, patient_id = NULL WHERE patient_id = #{patientId}，条件用patient_id而不是bed_id，因为出院时前端可能只传病人 ID。
4. 前端与联调：三个让页面不报错的细节
后端接口通了之后，前端联调是另一个翻车高发区。课设压缩包里的前端通常是 Vue 或原生 HTML + jQuery，不管哪种，下面三个细节不注意就会白屏。
4.1 床位状态的颜色映射与实时刷新
床位图是病房管理系统的门面。前端一般用不同颜色表示空闲、占用、预留、维修。常见做法是定义一个状态映射对象：
const bedStatusMap = { 0: { text: '空闲', color: '#67C23A' }, 1: { text: '占用', color: '#F56C6C' }, 2: { text: '预留', color: '#E6A23C' }, 3: { text: '维修', color: '#909399' } };渲染时用bedStatusMap[bed.status].color取色。坑在于后端返回的status可能是字符串"1"而不是数字1，JS 对象取值时bedStatusMap["1"]也能命中，但如果后端返回的是"占用"这种中文，映射就失效了。联调时先console.log一下接口返回的原始数据，确认字段类型。
实时刷新不要用setInterval轮询，课设演示时页面一直闪。用 WebSocket 或者简单的“操作后手动刷新”就行。如果非要用轮询，间隔至少 30 秒，并且加visibilitychange事件，页面不可见时暂停请求。
4.2 医嘱列表的分页与时间格式化
医嘱列表数据量可能上百条，必须分页。前端传page和size，后端用LIMIT和OFFSET。注意OFFSET在数据量大时性能差，但课设数据量小，不用过度设计。
时间格式化是另一个高频问题。后端返回的是2025-01-15T08:30:00.000+00:00这种 ISO 格式，直接显示很难看。用dayjs或moment转一下：
import dayjs from 'dayjs'; // 显示为 2025-01-15 16:30 const displayTime = dayjs(order.create_time).format('YYYY-MM-DD HH:mm');注意时区问题。如果后端存的是 UTC 时间，前端要转成本地时区。课设里常见做法是后端直接存NOW()，数据库时区设成+08:00，前端就不用转了。
4.3 跨域与登录拦截的配置
前后端分离时，跨域是必踩的坑。Spring Boot 里加一个配置类：
@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/api/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE") .allowCredentials(true) .maxAge(3600); } }allowedOriginPatterns("*")和allowCredentials(true)同时使用时，不能用allowedOrigins("*")，否则启动报错。这是 Spring 的硬性规定，踩过一次就记住了。
登录拦截用拦截器或过滤器都行，注意放行登录接口和静态资源。课设里经常出现“登录页面也要求登录”的死循环，就是拦截路径写成了/**没排除/login。
5. 避坑与排查：五条血泪经验
课设代码跑不起来，八成是下面五个问题之一。每条我都按“现象 → 原因 → 解决”整理，对着查就行。
现象一：启动报错Table 'xxx' doesn't exist。原因：数据库连接配置里的库名和实际建库名不一致，或者 SQL 文件没执行完。 解决：检查application.yml或config.py里的url，确认库名拼写。然后登录数据库执行SHOW TABLES，看表是否齐全。缺表就重新执行schema.sql，注意先DROP DATABASE IF EXISTS再重建，避免残留旧表。
现象二：床位分配后，病人列表里查不到该病人。原因：入院时只更新了bed表，忘了插patient表，或者事务没生效。 解决：检查admitPatient方法是否加了@Transactional，以及patientMapper.insert是否真的执行了。可以在方法里打日志，或者用SELECT * FROM patient WHERE patient_id = 'xxx'直接查库确认。
现象三：医嘱时间显示比实际早八小时。原因：数据库时区是 UTC，后端取出来没转时区。 解决：在 JDBC 连接串加serverTimezone=Asia/Shanghai，或者后端用@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8")注解格式化。
现象四：并发测试时两个请求同时占同一张床，都成功了。原因：occupyBed的 SQL 没加AND status = 0条件，或者加了但没判断返回行数。 解决：确认 SQL 带条件，并且业务层判断updated == 0时抛异常回滚。可以用ab或jmeter发两个并发请求验证。
现象五：前端页面空白，控制台报Uncaught TypeError: Cannot read property 'xxx' of undefined。原因：接口返回的数据结构和前端预期不一致，比如后端返回{ code: 200, data: {...} }，前端直接取res.xxx。 解决：在axios响应拦截器里统一处理，把res.data.data返回给业务层。或者联调时先console.log(res)确认结构。
提示：课设答辩前，把数据库连接池的
maxActive调小到 5，然后模拟几个并发请求，观察是否出现连接等待。这能帮你理解事务和连接池的关系，答辩时也是加分项。
6. 进阶技巧：用视图和存储过程把复杂查询压到数据库层
课设做到最后，往往会遇到“在院病人一览表”这种多表关联查询。如果每次都在 Java 或 Python 里拼 SQL，代码又长又容易出错。我一般会把这类查询做成数据库视图，前端直接查视图，后端代码干净很多。
CREATE VIEW v_inpatient_detail AS SELECT p.patient_id, p.name, p.gender, b.ward_no, b.bed_no, p.admission_date, DATEDIFF(NOW(), p.admission_date) AS days_in_hospital, (SELECT COUNT(*) FROM medical_order o WHERE o.patient_id = p.patient_id AND o.status = 1) AS active_orders FROM patient p LEFT JOIN bed b ON p.patient_id = b.patient_id WHERE p.status = 1;这个视图把病人基本信息、床位信息、住院天数和执行中医嘱数一次查出来。前端调/api/inpatient/list时，后端直接SELECT * FROM v_inpatient_detail，不用再写 JOIN。注意视图里的子查询active_orders在数据量大时性能一般，但课设数据量下完全没问题。
另一个技巧是用存储过程做月度统计。比如统计每个科室的床位使用率：
DELIMITER $$ CREATE PROCEDURE stat_bed_usage(IN start_date DATE, IN end_date DATE) BEGIN SELECT d.dept_name, COUNT(DISTINCT b.bed_id) AS total_beds, COUNT(DISTINCT ar.bed_id) AS used_beds, ROUND(COUNT(DISTINCT ar.bed_id) / COUNT(DISTINCT b.bed_id) * 100, 2) AS usage_rate FROM department d JOIN bed b ON d.dept_id = b.dept_id LEFT JOIN admission_record ar ON b.bed_id = ar.bed_id AND ar.admission_time BETWEEN start_date AND end_date GROUP BY d.dept_name; END$$ DELIMITER ;调用CALL stat_bed_usage('2025-01-01', '2025-01-31')就能出报表。存储过程的好处是逻辑固化在数据库层，多个前端（比如管理端和护士站）可以复用同一套统计逻辑，不用各自实现一遍。
验证视图和存储过程是否正确，我习惯用“对照法”：先手动写一条明细查询，把结果导出到 Excel，再执行视图或存储过程，对比两边数据是否一致。有一次我发现视图里的LEFT JOIN导致床位数为零的科室被过滤掉了，改成LEFT JOIN从department出发才修好。从那以后我每次写完视图，都强制用“小样本对照”跑一遍，确认行数和关键字段对得上再往下做。希望帮到你。
本文还有配套的精品资源，点击获取
