简介一套面向广东工业大学数据库课程设计的车站售票管理系统个人方案适合正在选题或实现课设的学生参考。系统覆盖车票购买与退票、车次与时刻表查询、售票情况统计并实现数据安全管理、操作员管理和权限设置等系统维护功能功能模块清晰数据库设计思路完整。资源包共100个文件压缩后仅4.65MB包含21个Java源码、72个class编译文件、1个SQL数据库脚本以及安装说明doc和工程配置文件。文件类型以Java源码和class文件为主配合SQL脚本可快速还原数据库结构安装说明书则指导从零配置环境便于直接导入运行或对照学习。目前已有1155人浏览学习。对于需要快速完成数据库课设或掌握售票系统开发流程的读者这份带完整源码和说明书的方案能帮助完成环境配置、读懂表结构设计并参照实现购票退票、查询统计和权限控制等核心功能无论是课程设计答辩还是后续功能扩展都能提供切实参考。1. 车站售票管理系统课设一门课把关系型数据库真正用起来车站售票管理系统是数据库课设里最常见也最容易做砸的题目。表面看只是查余票、下订单、管账号好像几张表就能收工实际做下去你会撞上 E-R 建模、范式取舍、事务边界、并发扣票这些只在课本里见过的东西。它的价值在于你第一次用一个完整业务场景把关系型数据库的核心机制串起来做完之后对 MySQL 的理解会从「会写 SELECT」升级到「敢说自己设计过业务系统」。这里就从建表开始讲到 JDBC 实现、并发控制最后是我自己踩过的一串坑照做就能复现答辩时也能把每个设计决定讲清楚。2. 车站售票系统的核心表设计E-R 模型到 7 张表的落地2.1 先画 E-R 图把车站、车次、旅客、订单的边界定清楚很多同学上手就写 CREATE TABLE写到一半发现字段对不上又回头改表这是课设里最浪费时间的事。我的习惯是先画 E-R 图再翻译成表结构。车站售票系统里最基本的实体是旅客账号、车站、车次外加订单这个核心业务实体。这里有一个关键区分车次是「模板」比如 G100 次从 A 站开往 B 站每天都跑真正被售卖的是「某年某月某日的 G100 次」这必须单独建一张运行计划表schedule否则你没法表达「今天的 G100 余票 3 张明天同车次余票 50 张」。旅客与订单是一对多订单与车次是多对多因为一张订单可能同时买 G100 和 D101 两张票所以要在中间拆出订单明细表。车站与车次之间是「途经」关系最简单做法是在车次表里用一个字段存途经站 ID 串。把这些关系在纸上画清楚建表就不会返工。2.2 建表 SQL7 张核心表的字段选择与主外键设计我一般建这几张表t_user旅客账号、t_station车站、t_train车次模板、t_schedule运行计划、t_order订单主表、t_order_item订单明细再加一张 t_refund退票记录。前六张覆盖主流程退票表是答辩时的加分项。以下 SQL 按 MySQL 8.0、InnoDB、utf8mb4 编写可以直接跑CREATE DATABASE railway_ticketing DEFAULT CHARACTER SET utf8mb4; USE railway_ticketing; CREATE TABLE t_user ( id BIGINT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(255) NOT NULL, -- 存 MD5/SHA-256 哈希值不存明文 phone VARCHAR(20), created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE t_station ( id BIGINT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(50) NOT NULL UNIQUE, city VARCHAR(50) ); CREATE TABLE t_train ( id BIGINT AUTO_INCREMENT PRIMARY KEY, train_no VARCHAR(20) NOT NULL UNIQUE, -- 车次号如 G100 train_type VARCHAR(10) NOT NULL, -- 高铁/动车/普快 dep_station_id BIGINT NOT NULL, arr_station_id BIGINT NOT NULL, stop_station_ids VARCHAR(500), -- 途经站 ID 串逗号分隔 FOREIGN KEY (dep_station_id) REFERENCES t_station(id), FOREIGN KEY (arr_station_id) REFERENCES t_station(id) ); CREATE TABLE t_schedule ( id BIGINT AUTO_INCREMENT PRIMARY KEY, train_id BIGINT NOT NULL, run_date DATE NOT NULL, dep_time TIME NOT NULL, arr_time TIME NOT NULL, total_seats INT NOT NULL, remain_seats INT NOT NULL, price DECIMAL(10,2) NOT NULL, version INT DEFAULT 0, -- 乐观锁版本号第 4 章会用到 UNIQUE KEY uk_train_date (train_id, run_date), FOREIGN KEY (train_id) REFERENCES t_train(id) );几个设计点我解释一下。主键统一用 BIGINT AUTO_INCREMENT演示数据量根本到不了 int 上限用 BIGINT 是养成习惯。t_user.username、t_train.train_no 加 UNIQUE这是业务上不可能重复的字段。票价用 DECIMAL(10,2) 而不是 FLOAT/DOUBLE浮点数的精度问题在票务系统里不能出现。t_schedule 上加 UNIQUE KEY uk_train_datetrain_id, run_date保证同一车次同一天只有一条运行计划这是数据完整性的硬约束。至于 version 字段现在先留着第 4 章讲乐观锁时直接复用提前设计能避免事后 ALTER TABLE 改结构。订单相关两张表如下CREATE TABLE t_order ( id BIGINT AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL UNIQUE, -- 业务订单号程序生成 user_id BIGINT NOT NULL, status TINYINT NOT NULL DEFAULT 0, -- 0待支付 1已支付 2已退票 total_price DECIMAL(12,2) NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (user_id) REFERENCES t_user(id) ); CREATE TABLE t_order_item ( id BIGINT AUTO_INCREMENT PRIMARY KEY, order_id BIGINT NOT NULL, schedule_id BIGINT NOT NULL, seat_no VARCHAR(10), price DECIMAL(10,2) NOT NULL, -- 下单时票价快照 FOREIGN KEY (order_id) REFERENCES t_order(id), FOREIGN KEY (schedule_id) REFERENCES t_schedule(id) );order_no 是程序生成的业务订单号时间戳加随机数和自增主键 id 分开。原因是主键不应携带业务含义而订单号要展示给用户、要支持查询。status 用 TINYINT 加注释比字符串省空间改状态就是改数字Java 端用常量对照读取。订单明细表把 order_id 和 schedule_id 关联起来注意它带了 price 快照——订单价格以下单时为准之后车次调价不影响已生成的订单这就是「快照」字段的意义。2.3 范式与冗余的取舍课设别把自己绕进 5NF范式是答辩一定会被问到的东西。最安全的回答是所有表满足第三范式3NF主键单一非主属性完全依赖主键且不存在传递依赖。但完全遵循范式在真实系统里反而不顺手比如 t_train.stop_station_ids 存逗号分隔的途经站 ID 串严格说违反第一范式属性不可再分但它让「查一趟车经过哪些站」变成一次字符串拆分而不是一次多行 JOIN。课设里这是可以接受的取舍答辩时主动讲「这里我做了反范式设计原因是减少一次关联查询」这是加分项。另一个常见取舍要不要把出发站、到达站名称冗余到 t_schedule我的建议是不冗余保持 JOIN。MySQL 对外键列有索引支撑演示数据量下性能差异根本感知不到把 name 冗余进去反而要面对「站改名后所有冗余都要同步」的维护问题。记住一句话范式是底线冗余是手段只有当你明确说出「我要减少哪一次查询成本」时冗余才成立。3. 用 JDBC MySQL 跑通售票主流程登录、余票查询与下单3.1 技术选型为什么课设选 JDBC Swing 而不是 Spring Boot很多组一上来就搭 Spring Boot MyBatis Vue结果一大半时间花在框架配置和环境问题上数据库课设最该展示的 SQL 和事务反而没篇幅讲。我的建议是用纯 JDBC 连接 MySQL 8.0界面用 Java Swing 或 JavaFX 完成。原因有三点第一JDBC 让你亲手写每一条 SQL事务、锁、连接管理全部可见答辩时老师问什么你都能答到代码层第二Swing 不需要任何前端知识一个人一周能写完界面第三数据库课设的评分重心是 E-R 图、建表、SQL 和事务设计框架只是外皮。如果老师明确要求 Web 形式用 Servlet JSP 也一样核心思路不变。3.2 数据库连接管理一个 DBUtil 类走遍全项目连接管理是整个项目的底座我习惯用一个 DBUtil 类统一负责拿连接避免每个类都写一遍 DriverManagerimport java.sql.Connection; import java.sql.DriverManager; import java.sql.SQLException; public class DBUtil { private static final String URL jdbc:mysql://localhost:3306/railway_ticketing ?useSSLfalseserverTimezoneAsia/ShanghaicharacterEncodingutf8; private static final String USER root; private static final String PASSWORD 你的数据库密码; static { try { Class.forName(com.mysql.cj.jdbc.Driver); } catch (ClassNotFoundException e) { throw new RuntimeException(MySQL 驱动加载失败, e); } } public static Connection getConnection() throws SQLException { return DriverManager.getConnection(URL, USER, PASSWORD); } }这段代码里的三个参数是血泪经验换来的。serverTimezoneAsia/Shanghai 解决第 5 章第一个坑characterEncodingutf8 解决中文乱码useSSLfalse 是因为本地连接不需要加密握手加上能省掉一堆告警日志。MySQL 8.0 的驱动类名是 com.mysql.cj.jdbc.Driver5.x 时代是 com.mysql.jdbc.Driver如果你从网上抄到旧代码加载驱动那行会直接报 ClassNotFoundException——先查驱动 jar 版本和类名是否匹配。课设阶段不需要连接池Druid、HikariCP 都可以不加一个简单的 DBUtil 足够还能让老师看清楚你懂 Connection 的生命周期。如果建的是普通 Java 项目把 mysql-connector-j 的 jar 放进项目里并 Add to Build Path 即可用 Maven 就加对应依赖坐标。3.3 登录与余票查询带参数预处理的两段基础 SQL登录和余票查询是整个系统的门面也是两段必须用 PreparedStatement 的 SQL。登录示例String sql SELECT id, username FROM t_user WHERE username ? AND password ?; try (Connection conn DBUtil.getConnection(); PreparedStatement ps conn.prepareStatement(sql)) { ps.setString(1, username); ps.setString(2, md5(password)); try (ResultSet rs ps.executeQuery()) { if (rs.next()) { // 登录成功把 rs.getLong(id) 存到当前会话 } else { // 用户名或密码错误 } } }注意两点。第一password 字段不存明文MD5 就可以想再扎实一点用 SHA-256 加盐答辩时这是安全意识的体现。第二用 PreparedStatement 的 ? 占位符而不是把变量拼进 SQL 字符串否则你会掉进第 5 章的最后一个坑。余票查询是列表页的核心要 JOIN 三张表把展示字段凑齐SELECT s.id, t.train_no, st1.name AS dep_name, st2.name AS arr_name, s.run_date, s.dep_time, s.arr_time, s.remain_seats, s.price FROM t_schedule s JOIN t_train t ON s.train_id t.id JOIN t_station st1 ON t.dep_station_id st1.id JOIN t_station st2 ON t.arr_station_id st2.id WHERE s.run_date BETWEEN ? AND ? AND s.remain_seats 0 ORDER BY s.run_date, s.dep_time;这段查询用 INNER JOIN 把运行计划、车次、车站串起来st1 和 st2 是同一张 t_station 表的两个别名分别代表出发站和到达站。WHERE 里用 run_date BETWEEN 和 remain_seats 0对应「按日期筛选」和「只显示有余票的车次」两个演示时最常点的功能。ORDER BY 按日期和发车时间排序贴近真实购票页的展示习惯。3.4 下订单事务里完成插入订单、扣减余票两步订票是整个系统里唯一必须开事务的地方因为它涉及两张以上表的写入。完整结构如下Connection conn DBUtil.getConnection(); try { conn.setAutoCommit(false); // 第1步锁住这条运行计划防止并发扣票第4章详解 String lockSql SELECT remain_seats FROM t_schedule WHERE id ? FOR UPDATE; try (PreparedStatement ps conn.prepareStatement(lockSql)) { ps.setLong(1, scheduleId); try (ResultSet rs ps.executeQuery()) { if (!rs.next() || rs.getInt(remain_seats) ticketCount) { throw new RuntimeException(余票不足); } } } // 第2步插入订单主表拿到自增主键 String insertOrder INSERT INTO t_order(order_no, user_id, status, total_price) VALUES (?, ?, 0, ?); long orderId; try (PreparedStatement ps conn.prepareStatement(insertOrder, Statement.RETURN_GENERATED_KEYS)) { ps.setString(1, orderNo); ps.setLong(2, userId); ps.setBigDecimal(3, totalPrice); ps.executeUpdate(); try (ResultSet keys ps.getGeneratedKeys()) { keys.next(); orderId keys.getLong(1); } } // 第3步插入订单明细 String insertItem INSERT INTO t_order_item(order_id, schedule_id, seat_no, price) VALUES (?, ?, ?, ?); try (PreparedStatement ps conn.prepareStatement(insertItem)) { ps.setLong(1, orderId); ps.setLong(2, scheduleId); ps.setString(3, seatNo); ps.setBigDecimal(4, price); ps.executeUpdate(); } // 第4步扣减余票affected rows 0 说明余票不够触发回滚 String updateSeat UPDATE t_schedule SET remain_seats remain_seats - ? WHERE id ? AND remain_seats ?; try (PreparedStatement ps conn.prepareStatement(updateSeat)) { ps.setInt(1, ticketCount); ps.setLong(2, scheduleId); ps.setInt(3, ticketCount); if (ps.executeUpdate() 0) { throw new RuntimeException(余票不足); } } conn.commit(); } catch (Exception e) { conn.rollback(); throw e; } finally { conn.close(); }这段流程的顺序有讲究先锁行再检查余票然后插入订单最后扣减余票。锁必须在检查之前否则两个窗口同时读到余票 1检查都通过后面就全乱套。UPDATE 语句里的 AND remain_seats ? 是第二道保险即使前面检查漏了这里 affected rows 为 0 也能让程序感知到并回滚。commit 之后才算真正卖出一张票任何一步失败都必须 rollback否则会出现有订单没扣票、或扣了票没有订单的脏数据。4. 两个窗口同时卖最后一张票并发扣票的三种解法4.1 先把问题复现出来丢失更新到底丢在哪把系统同时开两个窗口或开两个终端连同一个库去卖同一天同一车次的最后一张票你可能看到两个订单同时成功余票变成负数。这不是程序写错了是数据库并发下的经典问题——丢失更新。两个事务同时读到 remain_seats1都认为还有票各自往下执行扣减最终把一张票卖了两次。理解它的最好方式是在两个终端手动模拟-- 终端 A开启事务查询余票 BEGIN; SELECT remain_seats FROM t_schedule WHERE id 1; -- 读到 1还有票 -- 终端 B同时查同一张票 BEGIN; SELECT remain_seats FROM t_schedule WHERE id 1; -- 也读到 1还有票 -- 终端 A下单并扣减提交 UPDATE t_schedule SET remain_seats remain_seats - 1 WHERE id 1; COMMIT; -- 终端 B也下单并扣减提交 —— 余票变成 -1一张票卖出两次 UPDATE t_schedule SET remain_seats remain_seats - 1 WHERE id 1; COMMIT;先亲眼看一次这个结果后面三种解法你才能真正理解它们在解决什么。很多课设做到这里就停了但把并发问题解决了项目档次瞬间不一样答辩老师也最爱问这个点。4.2 悲观锁SELECT ... FOR UPDATE 把行锁住再处理悲观锁的思路是查余票之前先把这行锁住别人想碰必须等我提交。具体做法就是第 3 章第 4 节里的余票查询从普通 SELECT 改成SELECT remain_seats FROM t_schedule WHERE id ? FOR UPDATE;这条 SELECT 在事务内执行时会给命中行加排他锁直到事务提交或回滚才释放。注意它必须出现在 setAutoCommit(false) 之后、余票检查之前。锁住之后再查 remain_seats、判断够不够、插入订单、扣减余票整个流程串行化。两个窗口同时操作时第二个窗口的 SELECT ... FOR UPDATE 会阻塞直到第一个窗口提交——它的体验是「稍微卡了一下然后提示余票不足」。悲观锁适合票少、抢票冲突多的场景实现最简单课设里首选。代价是持有锁期间其他查询会被挡住所以事务体要尽量短别在锁内做耗时操作比如发短信、写日志都不能放进去。4.3 乐观锁与触发器兜底version 字段和数据库层防线乐观锁假设冲突很少不锁行靠版本号在更新时校验。建表时预留的 version 字段现在派上用场// 读取时带上版本号 String selectSql SELECT remain_seats, version FROM t_schedule WHERE id ?; // 更新时用版本号做条件 String updateSql UPDATE t_schedule SET remain_seats remain_seats - ?, version version 1 WHERE id ? AND version ? AND remain_seats ?; int rows ps.executeUpdate(); if (rows 0) { conn.rollback(); // 版本冲突或余票不足让用户重试 } else { conn.commit(); }关键在于 UPDATE 的 WHERE 条件带上了 version 和 remain_seats 两个约束。affected rows 0 说明这行在你读取之后被改过此时回滚并提示用户「余票发生变化请重试」。课设里可以两种都实现然后对比说明悲观锁胜在简单可靠乐观锁胜在无阻塞、适合读多写少的场景。最后再加一道数据库层的兜底防线。MySQL 8.0.16 之后 CHECK 约束会真正生效也可以直接建触发器DELIMITER // CREATE TRIGGER trg_schedule_check BEFORE UPDATE ON t_schedule FOR EACH ROW BEGIN IF NEW.remain_seats 0 THEN SIGNAL SQLSTATE 45000 SET MESSAGE_TEXT 余票不足; END IF; END// DELIMITER ;这个触发器在 UPDATE 时检查新余票只要是负数就 SIGNAL 抛错整个事务回滚。它是最后一道闸门就算应用层有 bug 绕过所有检查数据库也不会让余票变成负数。三层防线——应用检查、乐观锁/悲观锁、数据库约束——讲出来分数就稳了。5. 车站售票课设踩坑排查时间区、乱码、外键与未提交5.1 启动就报 server time zone 错误现象程序第一次连数据库就抛 java.sql.SQLException: The server time zone value йʱ is unrecognized。 原因MySQL 8.0 驱动要求连接串里明确时区而系统时区在驱动看来是乱码。 解决JDBC URL 里加 serverTimezoneAsia/Shanghai。如果部署到其他时区的机器改成对应时区。少数情况下还要在 MySQL 端执行 SET GLOBAL time_zone 8:00但课设环境一般不需要。这个报错出现频率极高基本每个连 MySQL 8.0 的新手都会撞一次看到乱码时区别慌就是少了这一个参数。5.2 查到中文全是乱码现象数据库里数据正常Java 界面里显示的却是 ?? 一串问号。 原因连接层字符集没指定MySQL 用了默认的 latin1 做传输。 解决URL 加 characterEncodingutf8建库时用 DEFAULT CHARACTER SET utf8mb4建表时也用 utf8mb4。三处对齐基本不会再乱码。如果还乱检查代码文件本身是不是 UTF-8 保存的Windows 记事本另存为时会悄悄改成 GBK这个玄学问题我帮别人调过好几次。5.3 删除车次报错外键约束挡在前面现象执行 DELETE FROM t_train WHERE id1; 报错 Cannot delete or update a parent row: a foreign key constraint fails。 原因t_schedule.train_id 是外键引用 t_train.idMySQL 默认的 RESTRICT 规则禁止删除被引用的父表行。 解决先查关联子表确认没有未完成订单再删或者建表时在外键上加 ON DELETE CASCADE。课设里我推荐显式两步删除逻辑清楚答辩时讲「我先删子表数据再删父表数据保证引用完整性」比一句 CASCADE 更有说服力-- 先查出引用了该车次的运行计划 SELECT id FROM t_schedule WHERE train_id 1; -- 确认没有未完成订单关联后再删除 DELETE FROM t_schedule WHERE train_id 1; DELETE FROM t_train WHERE id 1;5.4 订单插进去了界面却查不到现象程序里 insert 返回成功但重新打开查询界面看不到这条订单。 原因JDBC 手动 setAutoCommit(false) 之后忘了 commit程序退出时连接关闭未提交事务被回滚。 解决凡手动开启事务commit 和 rollback 必须成对出现finally 块中做回滚兜底。排查时可以执行 SHOW PROCESSLIST看有没有 Sleep 状态的连接长时间挂着那就是没提交的事务。血泪经验写完事务代码后故意在 commit 前抛个异常确认数据没有被写进去再恢复正常逻辑这样能验证 rollback 真的生效。5.5 登录框输入一个单引号就报错SQL 注入要堵上现象用户名输入 admin or 11程序直接抛 SQL 语法异常甚至可能绕过密码登录。 原因用 Statement 做了字符串拼接单引号破坏了 SQL 语句结构。 解决全部改用 PreparedStatement 占位符参数化查询下以上问题不复存在。这个问题答辩老师大概率会问答得上来是安全加分项答不上来等于告诉老师你的系统有后门。除了登录余票查询、订单查询所有涉及用户输入的地方都要走同样的写法。6. 答辩前冲刺演示数据生成、索引验证与两个自测场景6.1 演示数据用存储过程批量生成一个月的运行计划演示时最尴尬的事是点开余票查询全是空表手动 INSERT 几十行又浪费时间。我一般写一个存储过程批量生成数据DELIMITER // CREATE PROCEDURE generate_schedules(IN days INT) BEGIN DECLARE i INT DEFAULT 0; DECLARE d DATE; SET d CURDATE(); WHILE i days DO INSERT INTO t_schedule(train_id, run_date, dep_time, arr_time, total_seats, remain_seats, price) SELECT id, DATE_ADD(d, INTERVAL i DAY), 08:00, 10:30, 500, 500, 280.00 FROM t_train WHERE train_no G100; SET i i 1; END WHILE; END// DELIMITER ; CALL generate_schedules(30);这个存储过程按车次模板批量往 t_schedule 插入 days 天的运行计划一次 CALL 生成一个月的数据。演示时重点准备至少 5 个车站、3 个车次高铁/动车/普快各一、未来 30 天每天都有班次余票有满票、个位数、售罄三种状态。这三种状态能覆盖你所有功能演示点尤其「售罄」可以直接演并发那一段。6.2 用 EXPLAIN 验证索引 两个必测场景答辩前用 EXPLAIN 检查最常用的查询EXPLAIN SELECT * FROM t_schedule WHERE run_date 2025-06-15 AND remain_seats 0;如果 type 是 ALL 全表扫描、rows 很大说明索引没生效。t_schedule 上的 uk_train_datetrain_id, run_date覆盖了大多数查询如果按 run_date 单独筛选执行下面这条补一个普通索引ALTER TABLE t_schedule ADD INDEX idx_run_date (run_date);最后两个自测场景演示前必须跑一遍。场景一两个窗口同时买最后一张票看是否只有一个成功且余票不为负场景二支付后刷新订单列表、发起退票、再买同一车次走完整个生命周期。这两个场景能跑通你的课设就立住了。我自己做课设那年因为偷懒把扣票逻辑写在界面层演示时两个窗口一开就翻车全场看着我反复刷新。那次以后我养成了习惯凡是涉及库存、余额、扣减的 SQL一律先把并发场景想清楚再写代码锁在哪一行、事务边界在哪、失败怎么回滚。后来工作上写订票接口时直接复用了这套思路——交出去的作业不只是为了学分它值得你认真对待。希望帮到你。本文还有配套的精品资源点击获取