车站售票管理系统数据库课设：事务并发防超卖与验收骨架

简介车站售票管理系统数据库课程设计完整方案面向广东工业大学等高校本科生适合正在准备数据库课设、需要参考选题落地方式的学习者。系统覆盖车票购买与退票、车次与时刻表查询统计并延伸至数据备份恢复、操作员管理与权限设置等维护环节可对照理解从需求分析到功能实现的完整链路。压缩包共100个文件、约4.65MB以72个class与21个java源码为主体配套sql建库脚本、doc安装说明书、txt说明及jar依赖源码与文档对应便于导入数据库、还原环境并逐模块阅读实现逻辑。已有1159人学习说明该选题参考度较高。读者可获得的是一套可直接运行和拆解的课设范例既能参考表结构设计与SQL脚本也能借助安装说明快速部署还能从售票、退票、查询统计及权限维护等模块中梳理功能划分与交互流程为撰写报告、答辩演示和二次改造提供较完整的素材。1. 从「能跑」到「能答辩」一份车站售票管理系统数据库课设该有的骨架验收现场最尴尬的一幕不是界面丑而是两个售票窗口同时点“出票”系统把同一张硬座卖了两遍。这份车站售票管理系统数据库课程设计资源核心价值不在界面而在把余票、订单、退票三件事用表结构、约束和事务串起来。它适合正在做数据库课设、需要一套能讲清 E-R 图、能跑通并发测试、能扛住答辩追问的同学也适合想补数据库落地经验的初中级开发者。下面按建表、事务、避坑、验收的顺序拆尽量把每一步都落到可执行的 SQL 上。2. 需求到 E-R 图把售票窗口拆成五张主表和三张流水表很多数据库课设一上来就画二十多张表最后自己都说不清哪张表负责什么。车站售票管理系统的业务边界其实不宽查班次、看余票、下单、出票、退票最多再加一个操作员管理。真正容易讲乱的是“余票”到底放在班次表里还是单独建一张库存表“订单”和“车票”是不是一回事“退票”要不要单独留痕。先把这几个问题定下来E-R 图才不会变成摆设。2.1 先定业务边界一张票的生命周期我一般会把一张票的生命周期拆成四段班次发布、库存初始化、乘客下单、退票回滚库存。班次发布对应train_schedule库存初始化对应seat_stock下单对应orders和order_item退票对应refund_log。乘客信息落在passenger操作员落在operator车站落在station。这样拆分的好处是每一段都有明确的表承接答辩时被问到“余票变化记在哪”可以直接指到seat_stock.remaining和refund_log而不是含糊地说“在代码里减一”。这里有个常见误区把余票直接塞进train_schedule表做成remaining_seat一个字段。演示阶段看起来省事但只要出现席别差异就撑不住。同一趟车有硬座、硬卧、二等座价格和库存都不一样一个字段根本表达不了。所以库存表至少要细到“班次 席别”这一层seat_stock的主键可以用自增 ID业务唯一键用(schedule_id, seat_type)约束住。另一个边界是改签。课设周期紧的话改签可以不做但要在文档里写清楚“本系统暂不包含改签退票按原订单整单退”。不要嘴上说支持改签表里却没有改签流水验收时一追问就露馅。把不做的功能明确写出来比含糊承诺更加分。2.2 实体与联系五张主表加三张流水表下面这张表是我在做这类课设时常用的最小闭环字段不是越多越好关键是每个字段都能在业务里找到落点。表名作用关键字段关系station车站基础信息station_id、station_name、city被班次引用train_schedule班次schedule_id、train_no、from_station_id、to_station_id、depart_time多对一引用车站seat_stock班次席别库存stock_id、schedule_id、seat_type、price、total_seat、remaining多对一引用班次passenger乘客passenger_id、id_card、name、phone被订单引用operator售票操作员operator_id、login_name、role被订单引用orders订单主表order_id、passenger_id、operator_id、total_amount、status、create_time一对多订单明细order_item订单明细item_id、order_id、schedule_id、seat_type、qty、unit_price多对一引用订单和库存refund_log退票流水refund_id、order_id、refund_amount、refund_time、reason多对一引用订单实体联系上车站和班次是 1:N班次和库存是 1:N乘客和订单是 1:N订单和明细是 1:N。订单和班次之间看起来是多对多但被order_item拆开之后每一行明细都指向一个具体班次和席别关系就清楚了。退票流水单独一张表是为了保留“谁在什么时候退了多少钱”而不是直接改订单状态了事。课设答辩里老师很爱问“退票之后原订单还在不在”有这张流水表就能答得干净。2.3 从 E-R 到关系模式主外键怎么落画 E-R 图时可以把“下单”画成联系但落到关系模式就要变成外键。我的习惯是先把主表建出来再建流水表最后建约束。顺序大致是station→train_schedule→seat_stock→passenger→operator→orders→order_item→refund_log。如果顺序反了外键会一直报“被引用表不存在”这不是玄学就是建表顺序问题。关系模式里要特别留意两个点。第一order_item不要只存schedule_id还要存seat_type和unit_price。价格会变订单明细必须保留成交时的价格否则后面调价会把历史订单金额算错。第二orders.total_amount可以用冗余字段但它的值必须由明细汇总得出不能手填。课设里可以用存储过程或触发器维护也可以在插入明细后统一更新关键是文档里要说明一致性怎么保证。还有一个小细节身份证号、手机号这类字段不要用INT前导零会丢长度也不够。常见做法是用CHAR(18)存身份证用VARCHAR(20)存手机号。班次时间用DATETIME不要用字符串拼2025-05-01 08:00否则按时间排序和比较时全是坑。把这些字段类型定下来后面的 SQL 才不容易翻车。3. 建表与约束把「余票不为负」写进数据库而不是写进嘴课设里最容易拿分、也最容易被追问的是约束。很多同学把“余票不能小于零”写在 Java 或 Python 的if里数据库里一点防护都没有。演示时只走正常流程看不出问题一旦用两个会话同时下单或者手动改一条库存数据问题就暴露了。数据库课设的落脚点应该是让数据库自己守住底线。3.1 建表顺序与外键先看基础表的写法。下面这段 SQL 以 MySQL 的 InnoDB 引擎为例字符集统一用utf8mb4避免站名里的生僻字或特殊符号出现乱码。-- 车站表站名唯一避免重复录入 CREATE TABLE station ( station_id INT PRIMARY KEY AUTO_INCREMENT, station_name VARCHAR(64) NOT NULL, city VARCHAR(64) NOT NULL, UNIQUE KEY uk_station_name (station_name) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 班次表始发站和到达站都引用车站表 CREATE TABLE train_schedule ( schedule_id INT PRIMARY KEY AUTO_INCREMENT, train_no VARCHAR(16) NOT NULL, from_station_id INT NOT NULL, to_station_id INT NOT NULL, depart_time DATETIME NOT NULL, arrive_time DATETIME NOT NULL, CONSTRAINT fk_schedule_from FOREIGN KEY (from_station_id) REFERENCES station(station_id), CONSTRAINT fk_schedule_to FOREIGN KEY (to_station_id) REFERENCES station(station_id), CONSTRAINT ck_schedule_time CHECK (arrive_time depart_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这段代码里AUTO_INCREMENT负责代理主键UNIQUE KEY负责业务唯一性CHECK负责时间先后。外键名fk_schedule_from和fk_schedule_to要分开写因为同一个班次表两次引用车站表不分开命名后面排查会很痛苦。DATETIME比字符串更适合做时间比较ck_schedule_time能挡住“到达时间早于出发时间”的脏数据。接着建库存表。这张表是后面事务章节的主角字段不多但每一个都关键。-- 席别库存表同一班次同一席别只能有一条记录 CREATE TABLE seat_stock ( stock_id BIGINT PRIMARY KEY AUTO_INCREMENT, schedule_id INT NOT NULL, seat_type VARCHAR(16) NOT NULL, price DECIMAL(10,2) NOT NULL, total_seat INT NOT NULL, remaining INT NOT NULL, CONSTRAINT fk_stock_schedule FOREIGN KEY (schedule_id) REFERENCES train_schedule(schedule_id), CONSTRAINT ck_stock_remaining CHECK (remaining 0 AND remaining total_seat), UNIQUE KEY uk_schedule_seat (schedule_id, seat_type) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;金额用DECIMAL(10,2)不要用FLOAT或DOUBLE。浮点数在做金额汇总时会出现0.01的误差课设演示可能看不出来但答辩时被问到“为什么总金额和明细差一分钱”很难圆。uk_schedule_seat保证一个班次一个席别只有一条库存记录避免重复插入导致余票翻倍。注意较新的 MySQL 版本才会真正执行CHECK约束老版本只解析不生效。如果实验室环境版本较旧不要只依赖CHECK要补触发器或在存储过程里做判断。3.2 余票不为负CHECK 与触发器双保险CHECK能挡住直接UPDATE成负数的情况但它挡不住“先读后写”造成的超卖。为了在课设里讲清楚“数据库层防护”我通常再补一个BEFORE UPDATE触发器。触发器的写法要注意不能在触发器里再SELECT同一张表否则容易报错。直接用NEW.remaining判断即可。-- 更新库存前拦截负数余票 DELIMITER $$ CREATE TRIGGER trg_stock_before_update BEFORE UPDATE ON seat_stock FOR EACH ROW BEGIN IF NEW.remaining 0 THEN SIGNAL SQLSTATE 45000 SET MESSAGE_TEXT 余票不足禁止超卖; END IF; IF NEW.remaining NEW.total_seat THEN SIGNAL SQLSTATE 45000 SET MESSAGE_TEXT 余票不能超过总座位数; END IF; END$$ DELIMITER ;SIGNAL SQLSTATE 45000是用户自定义异常MESSAGE_TEXT会直接返回给调用方。这样即使应用层漏了判断数据库也会把非法更新拦下来。触发器里只做判断不写业务插入保持职责单一。答辩时如果被问“触发器和存储过程有什么区别”可以答触发器由事件自动触发适合做约束和审计存储过程由调用方显式执行适合封装完整业务事务。3.3 初始化数据与可重复执行课设包如果没有初始化脚本换一台机器就要手动插半天数据。我的做法是写一段可重复执行的种子 SQL用INSERT ... ON DUPLICATE KEY UPDATE避免反复插入报唯一键冲突。-- 初始化车站 INSERT INTO station (station_name, city) VALUES (模拟东站, 模拟市), (模拟西站, 模拟市) ON DUPLICATE KEY UPDATE city VALUES(city); -- 初始化班次 INSERT INTO train_schedule (train_no, from_station_id, to_station_id, depart_time, arrive_time) VALUES (G1001, 1, 2, 2025-06-01 08:00:00, 2025-06-01 10:30:00) ON DUPLICATE KEY UPDATE arrive_time VALUES(arrive_time); -- 初始化库存二等座 100 张一等座 20 张 INSERT INTO seat_stock (schedule_id, seat_type, price, total_seat, remaining) VALUES (1, 二等座, 56.50, 100, 100), (1, 一等座, 89.00, 20, 20) ON DUPLICATE KEY UPDATE price VALUES(price), total_seat VALUES(total_seat), remaining VALUES(remaining);这段脚本适合在演示前重置数据。ON DUPLICATE KEY UPDATE后面的VALUES()取的是本次准备插入的值不是表里旧值。把remaining一起重置能避免上一轮测试把余票扣到 0 后演示无法继续。实际课设里可以把这段放到init.sql每次验收前跑一遍比手动改表稳。4. 事务与并发同一张票被两个窗口同时卖出的复现与处理数据库课设如果只做增删改查很难拉开差距。真正能体现“数据库系统课程设计”含量的是并发场景。两个售票窗口同时卖最后一张票系统到底会不会超卖这个问题既能做实验又能讲清楚隔离级别、行锁和事务边界。下面这套复现步骤我在实验室里见过很多次翻车也见过同学用一句原子UPDATE就解决。4.1 复现超卖两个会话的手动实验先手动制造一次超卖。打开两个数据库会话假设seat_stock里schedule_id 1、seat_type 二等座的remaining是 1。两个会话都先读再写但不加锁。-- 会话 A START TRANSACTION; SELECT remaining FROM seat_stock WHERE schedule_id 1 AND seat_type 二等座; -- 读到 1先不提交 -- 会话 B START TRANSACTION; SELECT remaining FROM seat_stock WHERE schedule_id 1 AND seat_type 二等座; -- 也读到 1 -- 会话 A 继续 UPDATE seat_stock SET remaining 0 WHERE schedule_id 1 AND seat_type 二等座; INSERT INTO orders (passenger_id, operator_id, total_amount, status, create_time) VALUES (1, 1, 56.50, PAID, NOW()); COMMIT; -- 会话 B 继续 UPDATE seat_stock SET remaining 0 WHERE schedule_id 1 AND seat_type 二等座; INSERT INTO orders (passenger_id, operator_id, total_amount, status, create_time) VALUES (2, 1, 56.50, PAID, NOW()); COMMIT;最后查orders会发现两条订单都成功了但库存只扣了一次。这就是典型的丢失更新两个事务都基于“读到 1”的旧快照做判断后提交的更新覆盖了前一个。REPEATABLE READ隔离级别下普通SELECT是快照读不会阻塞也不会自动帮你把后一个事务挡住。要复现得稳定可以把两个会话的SELECT和UPDATE分开执行中间留几秒。演示时不要用图形化工具自动提交否则事务边界会乱。命令行客户端或者把自动提交关掉效果更直观。4.2 原子更新与行锁把判断和扣减合成一句解决超卖最直接的办法是把“判断余票”和“扣减余票”合成一条UPDATE让数据库在行锁里完成。-- 原子扣减只有 remaining 1 才会更新成功 UPDATE seat_stock SET remaining remaining - 1 WHERE schedule_id 1 AND seat_type 二等座 AND remaining 1; -- 应用层检查受影响行数 -- 如果返回 0说明余票不足直接回滚或提示用户这条语句的关键在WHERE remaining 1。InnoDB 执行UPDATE时会对匹配的行加排他锁两个会话同时进来后一个会等前一个提交然后基于最新值重新判断。受影响行数为 1 表示抢到了为 0 表示没抢到。应用层不要只判断异常还要判断affected rows这是很多人漏掉的一步。另一种写法是SELECT ... FOR UPDATE先锁行再判断。START TRANSACTION; SELECT remaining INTO remain FROM seat_stock WHERE schedule_id 1 AND seat_type 二等座 FOR UPDATE; -- 如果 remain 1回滚并提示 -- 否则继续扣减和插入订单 UPDATE seat_stock SET remaining remaining - 1 WHERE schedule_id 1 AND seat_type 二等座; COMMIT;FOR UPDATE是当前读会加行锁。它的好处是逻辑直观适合在存储过程里做多步判断缺点是锁持有时间更长如果后面还要调用外部接口容易把锁拖长。课设演示里两种写法都可以但文档里要写清楚原子UPDATE更轻FOR UPDATE更适合复杂事务。4.3 存储过程封装下单把事务边界收在数据库侧如果每次下单都靠应用层拼 SQL事务边界容易散。把下单封装成存储过程课设答辩时也更好讲。下面这个版本包含库存检查、订单插入、明细插入和异常回滚。DELIMITER $$ CREATE PROCEDURE sp_create_order( IN p_passenger_id INT, IN p_operator_id INT, IN p_schedule_id INT, IN p_seat_type VARCHAR(16), IN p_qty INT, OUT p_order_id BIGINT ) BEGIN DECLARE v_remaining INT; DECLARE v_price DECIMAL(10,2); DECLARE EXIT HANDLER FOR SQLEXCEPTION BEGIN ROLLBACK; RESIGNAL; END; START TRANSACTION; -- 锁定库存行防止并发超卖 SELECT remaining, price INTO v_remaining, v_price FROM seat_stock WHERE schedule_id p_schedule_id AND seat_type p_seat_type FOR UPDATE; IF v_remaining IS NULL THEN SIGNAL SQLSTATE 45000 SET MESSAGE_TEXT 库存记录不存在; END IF; IF v_remaining p_qty THEN SIGNAL SQLSTATE 45000 SET MESSAGE_TEXT 余票不足; END IF; UPDATE seat_stock SET remaining remaining - p_qty WHERE schedule_id p_schedule_id AND seat_type p_seat_type; INSERT INTO orders (passenger_id, operator_id, total_amount, status, create_time) VALUES (p_passenger_id, p_operator_id, v_price * p_qty, PAID, NOW()); SET p_order_id LAST_INSERT_ID(); INSERT INTO order_item (order_id, schedule_id, seat_type, qty, unit_price) VALUES (p_order_id, p_schedule_id, p_seat_type, p_qty, v_price); COMMIT; END$$ DELIMITER ;参数里p_qty是购买张数p_order_id是出参方便调用方拿到订单号。EXIT HANDLER FOR SQLEXCEPTION负责异常回滚RESIGNAL把原始错误继续抛给调用方避免错误被吞掉。SELECT ... FOR UPDATE锁住库存行LAST_INSERT_ID()取刚插入的订单主键。调用方式如下CALL sp_create_order(1, 1, 1, 二等座, 1, order_id); SELECT order_id;如果并发下出现死锁数据库会返回 1213 错误。常见做法是在应用层捕获这个错误后重试一次重试次数不要太多两到三次即可。存储过程里不要写WHILE无限重试否则演示时容易卡死。5. 避坑与排查课设验收现场最容易翻车的五件事数据库课设的坑大多不是语法不会而是环境、顺序和演示流程没控住。下面这五条是我在实验室里反复见到的翻车现场每一条都按“现象 → 原因 → 解决”拆开写照着排查能省不少时间。5.1 建表与初始化阶段的坑现象建order_item时报“Cannot add or update a child row”。原因先建了子表后建父表或者父表里没有对应的schedule_id。外键要求被引用列必须有匹配值建表顺序和插入顺序都要先父后子。解决按station→train_schedule→seat_stock→passenger→operator→orders→order_item的顺序建表和插数据排查时先查父表有没有那条记录再查子表的外键值。现象中文站名插进去变成问号。原因数据库、表、连接三层的字符集不一致。常见是表用了utf8连接用了latin1或者客户端没有设置字符集。解决建库建表统一utf8mb4连接串里显式指定字符集排查时执行SHOW VARIABLES LIKE character_set%;看character_set_client、character_set_connection、character_set_results是否一致。5.2 事务与演示阶段的坑现象触发器里查询同一张表报 1442 错误。原因MySQL 的触发器不能修改或查询正在被触发的表容易形成递归或锁冲突。解决触发器里只使用NEW和OLD的值做判断不要写SELECT ... FROM seat_stock需要跨表校验时把逻辑放到存储过程里。现象演示时余票扣成负数但代码里明明有if。原因应用层判断和数据库更新之间有时间窗口两个请求都读到了旧值或者演示时用了自动提交事务没包住。解决把扣减改成UPDATE ... WHERE remaining ?判断受影响行数或者用SELECT ... FOR UPDATE锁行演示前关掉自动提交确认事务边界。现象验收前跑了一遍测试数据乱了重新演示时余票全是 0。原因测试脚本没有重置数据或者remaining被手动改过没有恢复。解决准备一份可重复执行的init.sql每次演示前重置库存和订单不要直接改生产表先用SELECT确认当前值再决定是重置还是补数据。提示课设演示前至少留一遍“干净数据”的备份。用mysqldump导出结构加数据出了问题先恢复再排查比现场改表稳。6. 从能演示到能讲清视图、索引与验收顺序的收尾技巧课设做到能跑通下单只是及格线。验收时老师往往会追问“余票查询为什么慢”“订单列表走没走索引”“视图和表有什么区别”这些问题不需要把系统做得多复杂但要在关键查询上有准备。我的习惯是先把最常用的三条查询跑一遍EXPLAIN再决定加什么索引而不是一上来给每个字段都建索引。6.1 索引与执行计划别给每个字段都戴帽子下面这张表是我在车站售票场景里常用的索引取舍核心原则是“按查询路径建复合索引别按字段数量堆索引”。查询场景建议索引理由按班次和席别查余票seat_stock(schedule_id, seat_type)已经由唯一键覆盖等值查询直接命中按乘客查订单orders(passenger_id, create_time)先过滤乘客再按时间排序避免额外排序按订单查明细order_item(order_id)明细表按订单号回查频率高按班次查订单明细order_item(schedule_id, seat_type)统计某班次某席别销量时使用加完索引后用EXPLAIN看执行计划。重点看type是不是ALLkey是不是走了预期索引rows扫描行数是不是过大Extra里有没有Using filesort或Using temporary。-- 查看余票查询是否走唯一键 EXPLAIN SELECT remaining, price FROM seat_stock WHERE schedule_id 1 AND seat_type 二等座; -- 查看乘客订单列表是否走复合索引 EXPLAIN SELECT order_id, total_amount, create_time FROM orders WHERE passenger_id 1 ORDER BY create_time DESC;第一条查询理想情况下key是uk_schedule_seattype是const或ref。第二条如果key是idx_passenger_time并且Extra里没有Using filesort说明复合索引的顺序是对的。如果type是ALL先别急着加索引看看是不是条件字段类型不匹配比如passenger_id是字符串却传了数字隐式转换会让索引失效。视图方面可以建一个v_schedule_stock把班次、车站、库存拼在一起方便前台查询。视图不要嵌套太深课设里一层就够了。存储过程适合放下单和退票退票时要注意先更新orders.status再回补seat_stock.remaining最后写refund_log三步放在同一个事务里。退票的回补语句同样要带条件避免把库存回补到超过total_seat。6.2 验收演示的顺序先讲约束再跑并发验收时我一般按这个顺序走先打开 E-R 图讲实体和联系再跑建表脚本展示外键和CHECK然后插一条订单展示事务最后开两个会话演示并发下单。演示并发时不要一上来就讲隔离级别先让老师看到“两个会话同时买最后一张票只有一个成功”再解释UPDATE ... WHERE remaining 1和FOR UPDATE的区别。这样比背概念更有说服力。从那以后我每次交付数据库课设都强制自己先跑一遍“重置数据 → 单线程下单 → 双会话并发 → 退票回补 → 查执行计划”这条链路确认每一步都能复现再谈界面和文档。希望帮到你。本文还有配套的精品资源点击获取