Java+Oracle医院信息管理系统数据库课程设计实战指南

简介：这是一份面向数据库初学者与Java开发入门者的Oracle课程设计实战资源，聚焦医院信息系统数据库建模与前后端交互实现，适用于课程设计、大作业及工程实训等教学场景。资源包共45个文件，含36个Java源码（覆盖DAO、Service、UI层逻辑）、1个核心SQL建表与初始化脚本、1个数据库连接配置文件（database.properties）、1张关系模型图（PNG）及README说明文档等，整体压缩包仅323KB，轻量易部署。已有380人学习下载，体现其在教学实践中的实用认可度。用户可直接运行Java程序连接Oracle数据库（默认地址test.linyer.cn:9999），快速掌握JDBC连接配置、CRUD操作、ER模型落地及前后端协同开发流程；所有代码结构清晰、注释完整，SQL语句规范适配Oracle语法，是理解医疗领域业务建模与数据库集成的典型参考案例。

1. 项目缘起与核心价值：为什么是Java+Oracle的医院系统？

如果你正在为数据库课程设计选题发愁，或者想找一个能真正串联起Java后端、Oracle数据库和实际业务逻辑的实战项目，那么一个医院信息管理系统（HIS）的数据库设计与实现，绝对是一个“含金量”极高的选择。这不仅仅是因为“医院系统”听起来很专业、很复杂，更重要的是，它几乎涵盖了数据库课程设计的所有核心考点：从复杂业务的概念模型（E-R图）到严谨的物理表结构设计，从多表关联查询到存储过程、触发器等高级数据库对象的使用，再到通过Java程序（JDBC或MyBatis等框架）进行完整的增删改查（CRUD）操作。选择Java和Oracle这对经典组合，更是有意为之——Java在企业级应用中的稳定性和生态成熟度无需多言，而Oracle数据库以其强大的事务处理能力、完善的安全机制和复杂的SQL功能，一直是金融、医疗等关键行业的核心选择。用它们来构建一个医院系统的“数据库内核”，你能学到的绝不仅仅是书本上的SQL语句，而是如何将一个真实的、高并发的业务场景，通过严谨的技术栈落地。

我当年做这个课程设计时，最大的收获不是最终交上去的那份报告和代码，而是在反复琢磨“医生排班表该怎么设计才能避免冲突”、“药品库存变动如何保证事务一致性”这些具体问题时，对数据库理论产生的深刻理解。你会发现，第三范式（3NF）不是为了考试而存在的，是为了防止数据冗余导致更新异常；事务的ACID特性也不是枯燥的概念，是确保不会出现“药扣了但账单没生成”这种严重错误的基石。接下来，我就以这个“医院系统数据库”课程设计为例，拆解从零到一构建它的完整过程，并分享那些在标准教材里不会写的“踩坑”经验和性能考量。

2. 业务蓝图与核心实体关系拆解

设计数据库的第一步，永远是理解业务，而不是直接打开Navicat或SQL Developer建表。医院系统的核心业务流程可以简化为：患者挂号 -> 医生接诊（生成病历） -> 开具处方或检查检验单 -> 患者缴费 -> 执行处方（取药）或检查检验 -> 完成就诊。围绕这个流程，我们需要抽取出最关键的几个实体（Entity）以及它们之间的关系（Relationship）。

2.1 核心实体定义

1. 患者（PATIENT）：系统的服务主体。关键属性包括：患者ID（主键）、姓名、性别、出生日期、身份证号（唯一约束）、联系电话、医保卡号、过敏史等。这里身份证号一定要设唯一约束，这是业务强要求，防止重复建档。
2. 员工（STAFF）：这是一个广义实体，包含医生、护士、药剂师、收费员等所有医院工作人员。通常设计一个STAFF表，通过“职位类型”或“角色ID”字段来区分。属性包括：员工ID（主键）、姓名、性别、所属科室ID（外键）、职位、登录密码（加密存储）等。将医生作为员工的一种，便于权限和账户的统一管理。
3. 科室（DEPARTMENT）：医院的组织单元，如内科、外科、儿科。属性包括：科室ID（主键）、科室名称、科室简介、所属楼栋等。它是连接医生和诊室的关键节点。
4. 诊室（CONSULTING_ROOM）：医生接诊的具体地点。属性包括：诊室ID、诊室号、所属科室ID（外键）。一个科室有多个诊室。
5. 医生排班（SCHEDULE）：这是业务逻辑的难点之一。它描述了“哪位医生”、“在哪个诊室”、“什么时间段”、“提供何种类型的号源（如专家号、普通号）”。这是一个典型的多对多关系的实例（医生-诊室-时间段），需要拆解成一个独立的关联表。其属性包括：排班ID、医生ID（外键）、诊室ID（外键）、排班日期、时段（如“上午”、“下午”或具体时间范围）、号源总数、剩余号源、挂号费用等。
6. 挂号记录（REGISTRATION）：患者挂号的记录，是患者与医生排班之间的纽带。属性包括：挂号单号（主键）、患者ID（外键）、排班ID（外键）、挂号时间、挂号状态（如“已预约”、“已就诊”、“已取消”）、实际就诊序号等。这里有个关键设计：实际就诊序号不应简单采用自增ID，而应在患者签到后，根据该排班下“已签到”的挂号记录动态生成（如1,2,3…），这通常需要一个触发器或应用程序逻辑来实现。
7. 病历（MEDICAL_RECORD）：每次就诊的核心记录。属性包括：病历ID（主键）、挂号记录ID（外键，一对一关联）、主诉、现病史、既往史、体格检查、初步诊断、处理意见等。大文本字段（如主诉、诊断）建议使用CLOB类型。
8. 药品（MEDICINE）：药品目录。属性包括：药品ID（主键）、药品编码（唯一）、通用名、商品名、规格、单位（盒/瓶/支）、库存数量、库存预警下限、进货单价、零售单价、生产厂家等。价格字段务必使用NUMBER类型并指定精度（如NUMBER(10,2)），避免浮点数精度问题。
9. 处方（PRESCRIPTION）：医生为患者开具的用药清单。一个处方对应一次就诊（病历），包含多个药品明细。因此需要两个表：
   • PRESCRIPTION_HEADER（处方头）：处方ID（主键）、病历ID（外键）、开具时间、处方状态（待缴费、已发药、已作废）。
   • PRESCRIPTION_DETAIL（处方明细）：明细ID、处方ID（外键）、药品ID（外键）、数量、用法（口服/外用）、频次（一日几次）、单次剂量、用药天数、备注。这里“数量”指发给患者的药品总数量（如2盒）。
10. 收费项目（CHARGE_ITEM）：包括药品费、检查费、检验费、治疗费、挂号费等所有可收费项。属性包括：项目ID、项目名称、项目类型、单价、规格单位。它与药品表可能是重叠的，但通常独立设计，药品作为一种特殊的收费项目，通过项目类型关联。
11. 收费记录（CHARGE_RECORD）：记录每一笔费用。属性包括：收费单号（主键）、患者ID（外键）、关联业务ID（如处方ID、检查单ID）、项目ID（外键）、数量、应收金额、实收金额、收费时间、收费员ID、支付方式等。设计上常采用“聚合支付”思路，一次缴费可能对应多个收费记录。
12. 库存流水（INVENTORY_TRANSACTION）：记录药品每一次入库、出库（发药）、报损的明细。这是实现库存精准管理、支持追溯的关键。属性包括：流水ID、药品ID（外键）、交易类型（入库/出库/报损）、关联业务单号（如采购单号、处方ID）、变化数量（正数表示入库，负数表示出库）、交易后结存数量、操作时间、操作员ID。通过触发器，在每次流水插入时自动更新MEDICINE表的库存数量，可以保证数据一致性。

2.2 核心关系与ER图要点

基于以上实体，几个核心的多对多（M:N）关系需要转换为关联表：

• 医生-诊室-时间段->SCHEDULE表。
• 处方-药品->PRESCRIPTION_DETAIL表。
• 患者-费用项目->CHARGE_RECORD表。

绘制E-R图时，务必清晰标出主键（PK）、外键（FK）和关系的基数（1:1, 1:N, M:N）。一个清晰的E-R图是后续建表SQL的蓝图，也能帮你提前发现设计缺陷，比如循环依赖或数据冗余。

3. Oracle数据库物理设计与高级特性应用

有了清晰的逻辑模型，接下来就是在Oracle中创建物理表结构。这里不仅是执行CREATE TABLE那么简单，更要充分利用Oracle的特性来保证数据的完整性、安全性和性能。

3.1 建表语句与约束设计

以PATIENT表和PRESCRIPTION_DETAIL表为例，展示如何编写严谨的DDL语句。

-- 患者表 CREATE TABLE PATIENT ( PATIENT_ID NUMBER(10) PRIMARY KEY, -- 使用序列自增主键 ID_CARD VARCHAR2(18) NOT NULL UNIQUE, -- 身份证号，唯一且非空 NAME VARCHAR2(50) NOT NULL, GENDER CHAR(1) CHECK (GENDER IN ('M', 'F')), -- 检查约束 BIRTH_DATE DATE, PHONE VARCHAR2(11), MEDICAL_INSURANCE_NUM VARCHAR2(30), ALLERGY_HISTORY CLOB, -- 大文本使用CLOB CREATE_TIME TIMESTAMP DEFAULT SYSTIMESTAMP NOT NULL, UPDATE_TIME TIMESTAMP DEFAULT SYSTIMESTAMP NOT NULL ); COMMENT ON TABLE PATIENT IS '患者信息表'; COMMENT ON COLUMN PATIENT.GENDER IS 'M:男, F:女'; -- 处方明细表 CREATE TABLE PRESCRIPTION_DETAIL ( DETAIL_ID NUMBER(10) PRIMARY KEY, PRESCRIPTION_ID NUMBER(10) NOT NULL, MEDICINE_ID NUMBER(10) NOT NULL, QUANTITY NUMBER(8,2) NOT NULL CHECK (QUANTITY > 0), -- 数量必须大于0 USAGE_METHOD VARCHAR2(100), -- 用法 FREQUENCY VARCHAR2(50), -- 频次 SINGLE_DOSE VARCHAR2(50), -- 单次剂量 DAYS NUMBER(3), -- 用药天数 NOTES VARCHAR2(500), CONSTRAINT FK_DETAIL_PRESCRIPTION FOREIGN KEY (PRESCRIPTION_ID) REFERENCES PRESCRIPTION_HEADER(PRESCRIPTION_ID) ON DELETE CASCADE, CONSTRAINT FK_DETAIL_MEDICINE FOREIGN KEY (MEDICINE_ID) REFERENCES MEDICINE(MEDICINE_ID) );

关键设计点：

• 主键策略：Oracle没有自增关键字，主流方案是使用SEQUENCE（序列）+TRIGGER（触发器），或直接在插入时使用SEQUENCE.NEXTVAL。课程设计中建议使用序列。
• 字段类型与长度：VARCHAR2比VARCHAR更推荐。长度定义需合理，如手机号VARCHAR2(11)。金额使用NUMBER(p,s)。
• 约束：除了主键、外键，务必善用NOT NULL、UNIQUE、CHECK约束。它们在数据库层面提供了最基础、最有效的数据校验。
• 注释：使用COMMENT ON语句为表和列添加注释，这对后期维护和团队协作至关重要。

3.2 序列与触发器的实战应用

序列用于生成唯一的主键ID。

-- 为PATIENT表创建序列 CREATE SEQUENCE SEQ_PATIENT_ID START WITH 10000001 -- 从10000001开始 INCREMENT BY 1 NOCACHE NOCYCLE; -- 创建触发器，在插入前自动获取序列值 CREATE OR REPLACE TRIGGER TRI_PATIENT_BEFORE_INSERT BEFORE INSERT ON PATIENT FOR EACH ROW BEGIN IF :NEW.PATIENT_ID IS NULL THEN SELECT SEQ_PATIENT_ID.NEXTVAL INTO :NEW.PATIENT_ID FROM DUAL; END IF; :NEW.CREATE_TIME := SYSTIMESTAMP; :NEW.UPDATE_TIME := SYSTIMESTAMP; EXCEPTION WHEN OTHERS THEN RAISE_APPLICATION_ERROR(-20001, '生成患者ID失败: ' || SQLERRM); END; /

这个触发器做了两件事：1) 自动填充主键；2) 自动记录创建和更新时间。对于UPDATE操作，可以创建另一个触发器来单独更新UPDATE_TIME。

3.3 存储过程与函数：封装业务逻辑

将复杂的业务逻辑封装在数据库端，可以提高效率并保证一致性。例如，“挂号”这个动作，需要检查号源、生成挂号记录、更新排班表剩余号源。这应该是一个原子操作。

CREATE OR REPLACE PROCEDURE PROC_REGISTER_PATIENT ( p_patient_id IN NUMBER, p_schedule_id IN NUMBER, p_registration_id OUT NUMBER, p_err_msg OUT VARCHAR2 ) IS v_available_count NUMBER; v_current_seq NUMBER; BEGIN -- 1. 检查号源是否充足 (使用SELECT FOR UPDATE锁定行，防止并发超号) SELECT REMAINING_SLOTS INTO v_available_count FROM SCHEDULE WHERE SCHEDULE_ID = p_schedule_id AND REMAINING_SLOTS > 0 FOR UPDATE WAIT 5; -- 等待5秒，避免死锁 IF v_available_count IS NULL THEN p_err_msg := '号源已用完或排班不存在'; RETURN; END IF; -- 2. 生成挂号记录 (获取下一个就诊序号) SELECT NVL(MAX(VISIT_SEQUENCE), 0) + 1 INTO v_current_seq FROM REGISTRATION WHERE SCHEDULE_ID = p_schedule_id AND STATUS = '已签到'; INSERT INTO REGISTRATION (REGISTRATION_ID, PATIENT_ID, SCHEDULE_ID, REGISTER_TIME, STATUS, VISIT_SEQUENCE) VALUES (SEQ_REGISTRATION_ID.NEXTVAL, p_patient_id, p_schedule_id, SYSTIMESTAMP, '已预约', v_current_seq) RETURNING REGISTRATION_ID INTO p_registration_id; -- 3. 更新排班表剩余号源 UPDATE SCHEDULE SET REMAINING_SLOTS = REMAINING_SLOTS - 1 WHERE SCHEDULE_ID = p_schedule_id; COMMIT; p_err_msg := NULL; -- 成功 EXCEPTION WHEN OTHERS THEN ROLLBACK; p_err_msg := '挂号失败: ' || SQLERRM; p_registration_id := NULL; END; /

这个存储过程体现了事务的完整性。它使用了SELECT ... FOR UPDATE进行悲观锁，确保在高并发挂号场景下不会出现“号源超卖”的问题。Java程序只需调用这个存储过程，并处理返回的错误信息即可。

3.4 视图与索引：提升查询效率与安全性

视图：可以创建视图来简化复杂查询，或隐藏敏感数据。

-- 创建一个视图，展示今日所有医生的排班及剩余号源 CREATE OR REPLACE VIEW V_DOCTOR_SCHEDULE_TODAY AS SELECT s.SCHEDULE_ID, d.NAME AS DEPT_NAME, st.NAME AS DOCTOR_NAME, cr.ROOM_NUMBER, s.SCHEDULE_DATE, s.TIME_SLOT, s.TOTAL_SLOTS, s.REMAINING_SLOTS, s.FEE FROM SCHEDULE s JOIN STAFF st ON s.DOCTOR_ID = st.STAFF_ID JOIN DEPARTMENT d ON st.DEPT_ID = d.DEPT_ID JOIN CONSULTING_ROOM cr ON s.ROOM_ID = cr.ROOM_ID WHERE s.SCHEDULE_DATE = TRUNC(SYSDATE) -- 今天 AND st.POSITION = '医生' ORDER BY d.DEPT_ID, s.TIME_SLOT;

索引：合理的索引是性能的关键。除了主键自动创建的索引，以下字段应考虑建立索引：

• PATIENT(ID_CARD)：身份证查询频繁。
• REGISTRATION(PATIENT_ID, STATUS)：联合索引，用于查询患者的历史挂号记录。
• SCHEDULE(SCHEDULE_DATE, DOCTOR_ID)：用于按日期和医生查询排班。
• CHARGE_RECORD(PATIENT_ID, CHARGE_TIME)：用于查询患者消费记录。

CREATE INDEX IDX_REG_PATIENT_STATUS ON REGISTRATION(PATIENT_ID, STATUS); CREATE INDEX IDX_CHARGE_PATIENT_TIME ON CHARGE_RECORD(PATIENT_ID, CHARGE_TIME);

4. Java后端服务层设计与关键实现

数据库设计好后，我们需要用Java构建一个服务层来操作它。这里我以经典的Servlet/JSP（或Spring MVC） + JDBC为例，但强烈建议在课程设计中尝试使用MyBatis或Spring Data JPA来简化数据库操作。

4.1 数据访问层（DAO）模式与连接管理

首先，需要一个可靠的数据库连接工具类。绝对不要在每个方法里都创建和关闭连接！使用Druid或HikariCP这样的连接池是生产级做法，课程设计中至少要做到单例模式的管理。

// 简化的数据库工具类 (使用Druid连接池) public class DBUtil { private static DataSource dataSource; static { try { // 读取配置文件初始化Druid Properties props = new Properties(); props.load(DBUtil.class.getClassLoader().getResourceAsStream("druid.properties")); dataSource = DruidDataSourceFactory.createDataSource(props); } catch (Exception e) { throw new ExceptionInInitializerError("初始化数据库连接池失败: " + e); } } public static Connection getConnection() throws SQLException { return dataSource.getConnection(); } // ... 其他关闭资源的方法 }

然后，为每个实体创建DAO接口和实现类。以PatientDAO为例：

public interface PatientDAO { Patient findById(Long id) throws SQLException; Patient findByIdCard(String idCard) throws SQLException; List<Patient> findByName(String name) throws SQLException; Long insert(Patient patient) throws SQLException; boolean update(Patient patient) throws SQLException; // ... 其他方法 } public class PatientDAOImpl implements PatientDAO { @Override public Patient findByIdCard(String idCard) throws SQLException { String sql = "SELECT * FROM PATIENT WHERE ID_CARD = ?"; try (Connection conn = DBUtil.getConnection(); PreparedStatement pstmt = conn.prepareStatement(sql)) { pstmt.setString(1, idCard); try (ResultSet rs = pstmt.executeQuery()) { if (rs.next()) { return mapResultSetToPatient(rs); // 一个将ResultSet映射到Patient对象的方法 } } } return null; } // ... 其他方法的实现 }

关键点：使用PreparedStatement防止SQL注入，使用try-with-resources确保资源自动关闭。

4.2 业务逻辑层（Service）与事务控制

DAO层只负责数据存取，业务逻辑（如挂号、收费）应放在Service层。事务控制是Service层的核心职责。

public class RegistrationService { private PatientDAO patientDAO = new PatientDAOImpl(); private ScheduleDAO scheduleDAO = new ScheduleDAOImpl(); private RegistrationDAO registrationDAO = new RegistrationDAOImpl(); public RegistrationResult registerPatient(Long patientId, Long scheduleId) { Connection conn = null; RegistrationResult result = new RegistrationResult(); try { conn = DBUtil.getConnection(); conn.setAutoCommit(false); // 开启事务 // 1. 业务校验（可选，部分校验已在存储过程） Patient patient = patientDAO.findById(patientId); Schedule schedule = scheduleDAO.findById(scheduleId); if (patient == null || schedule == null || schedule.getRemainingSlots() <= 0) { result.setSuccess(false); result.setMessage("患者或排班信息无效，或号源已空"); conn.rollback(); return result; } // 2. 调用存储过程执行核心挂号逻辑 String sql = "{call PROC_REGISTER_PATIENT(?, ?, ?, ?)}"; try (CallableStatement cstmt = conn.prepareCall(sql)) { cstmt.setLong(1, patientId); cstmt.setLong(2, scheduleId); cstmt.registerOutParameter(3, Types.NUMERIC); // 输出参数：挂号ID cstmt.registerOutParameter(4, Types.VARCHAR); // 输出参数：错误信息 cstmt.execute(); String errMsg = cstmt.getString(4); if (errMsg != null) { result.setSuccess(false); result.setMessage(errMsg); conn.rollback(); } else { Long regId = cstmt.getLong(3); result.setSuccess(true); result.setRegistrationId(regId); result.setMessage("挂号成功，就诊序号请于签到后获取"); conn.commit(); // 提交事务 } } } catch (SQLException e) { try { if (conn != null) conn.rollback(); } catch (SQLException ex) {} result.setSuccess(false); result.setMessage("系统错误: " + e.getMessage()); // 这里应该记录日志，而不是简单打印 e.printStackTrace(); } finally { DBUtil.closeConnection(conn); } return result; } }

这个RegistrationService展示了典型的事务控制模式：关闭自动提交 -> 执行一系列数据库操作 -> 成功则提交，失败则回滚。注意，核心的并发控制（锁号源）我们已经下推到数据库的存储过程中了，这是更可靠的做法。

4.3 控制器层与前端交互

在Servlet或Spring MVC的Controller中，调用Service层，处理HTTP请求，并返回JSON或转发到JSP页面。

// 使用Spring MVC @RestController示例 @RestController @RequestMapping("/api/registration") public class RegistrationController { @Autowired private RegistrationService registrationService; @PostMapping("/doRegister") public ResponseEntity<Map<String, Object>> doRegister(@RequestBody Map<String, Long> params) { Long patientId = params.get("patientId"); Long scheduleId = params.get("scheduleId"); Map<String, Object> resultMap = new HashMap<>(); if (patientId == null || scheduleId == null) { resultMap.put("success", false); resultMap.put("msg", "参数缺失"); return ResponseEntity.badRequest().body(resultMap); } RegistrationResult result = registrationService.registerPatient(patientId, scheduleId); resultMap.put("success", result.isSuccess()); resultMap.put("data", result); return ResponseEntity.ok(resultMap); } }

5. 课程设计报告核心要点与演示系统构建

一份优秀的课程设计报告，除了代码，更需要清晰的文档来展示你的设计思路和实现过程。

5.1 报告内容组织建议

1. 需求分析：用文字和用例图描述系统的主要功能模块（如挂号、诊间、药房、收费、系统管理）。
2. 概念结构设计：给出完整的E-R图，并附上实体和属性的详细说明。
3. 逻辑结构设计：将E-R图转换为关系模式（表结构），说明转换规则（如M:N关系如何分解）。
4. 物理结构设计：列出所有表的详细DDL语句（包含字段名、类型、约束、注释）。这是重点。
5. 数据库实施：
   • 创建表空间、用户、权限分配的SQL。
   • 插入必要的初始数据（如科室、药品目录、管理员账号）的SQL脚本。
   • 创建序列、触发器、存储过程、函数、视图的SQL脚本。
   • 创建索引的SQL。
6. 应用程序设计：
   • 系统架构图（如MVC）。
   • 关键类的类图（如Patient, PatientDAO, RegistrationService）。
   • 核心功能的流程图或时序图（如挂号时序图）。
   • 关键功能的代码片段及说明（如上述的存储过程调用和事务控制）。
7. 系统测试：
   • 测试用例表（功能、输入、预期输出、实际输出）。
   • 典型界面的截图（如挂号界面、查询界面）。
   • 执行复杂查询（如多表关联查询患者所有历史处方）的SQL语句和结果截图。
8. 总结与心得：谈谈你在设计过程中遇到的挑战（如并发挂号、库存事务）、解决方案的选择（为什么用触发器更新库存？为什么把核心逻辑放在存储过程？），以及对Java和Oracle配合使用的体会。

5.2 快速构建可演示的子系统

为了在答辩或检查时有一个可操作的演示，不必实现所有功能。建议聚焦一个核心流程，实现其完整闭环。“患者挂号 -> 医生接诊（模拟）-> 开具处方 -> 药房发药”这个流程就非常典型。

1. 前端：可以使用简单的HTML + jQuery，或者Thymeleaf、JSP模板。重点在于功能，不在样式。
2. 核心演示页面：
   • 挂号页面：下拉框选择科室、医生、排班时间，输入患者身份证号（可模拟查询），点击挂号。
   • 医生工作台页面：模拟医生登录，列出已挂号待就诊患者列表。点击“接诊”，跳转到“开具处方”页面。
   • 开具处方页面：选择药品、填写用法用量，保存处方。保存后应自动生成待缴费的收费记录。
   • 药房发药页面：列出状态为“已缴费”的处方，点击“发药”，系统检查库存并扣减，更新处方和库存流水状态。
3. 演示数据准备：编写详细的INSERT脚本，创建几个科室、医生、排班、药品和患者。确保数据之间有合理的关联，方便演示。

5.3 常见踩坑点与调试技巧

• Oracle连接错误：ORA-28547通常意味着客户端与服务器版本不匹配或网络配置问题。确保你的JDBC驱动（ojdbc.jar）版本与Oracle数据库版本兼容。TNS配置也要检查。
• 中文乱码：确保数据库字符集（如AL32UTF8）、Java程序编码（UTF-8）、以及连接字符串中的characterEncoding参数一致。在连接URL中添加?useUnicode=true&characterEncoding=UTF-8。
• 事务未提交：在Java中执行了DML（INSERT/UPDATE/DELETE）但没提交，在其他会话或工具里查不到数据。记得在Service层正确管理commit()和rollback()。调试时可以在SQL Developer里手动COMMIT或检查隔离级别。
• 触发器递归调用：如果在A表的触发器中更新了A表自身，可能导致递归调用直至超出最大递归深度错误（ORA-00036）。设计时要避免这种逻辑。
• 性能问题：对于课程设计的小数据量可能不明显，但要有关注点。避免在循环中执行SQL（N+1查询问题），尽量用IN或批量操作。复杂的报表查询，考虑用物化视图定期刷新。
• 日期处理：Java中的java.util.Date、java.sql.Date、java.sql.Timestamp与Oracle中的DATE、TIMESTAMP类型容易混淆。在插入参数时，使用PreparedStatement.setTimestamp()。在查询时，注意Oracle的DATE类型也包含时间部分。使用TRUNC(SYSDATE)来获取当天日期（时间部分为00:00:00）进行比对是非常常用的技巧。

做这个课程设计的过程，就像搭建一个精密的机械系统。数据库表是齿轮和轴承，SQL和PL/SQL是传动原理，Java程序是控制系统。当你看到一次挂号操作，能流畅地驱动排班、病历、处方、收费、库存等一系列表协同工作时，那种对系统级开发的理解会深刻得多。这远比单纯写几个增删改查的页面有价值。最后，记得把你的数据库脚本、代码、报告整理清楚，这不仅是作业，更是你第一份值得放入简历的“项目经验”。

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