简介：《数据库课程设计——教材征订管理系统》是一份完整的设计文档，面向高校计算机、软件工程等专业需要完成数据库课程设计或管理信息系统设计的学生。文档采用SQL Server 2000与PowerBuilder 9.0，从教学管理场景出发，梳理了教材征订、采购、发行、书目替换及数据录入查询等功能，覆盖系统登录、教材信息管理、出入库管理、学生书费管理、系统管理和综合查询等模块。内容包含需求分析的数据流图与数据字典、总体设计的E-R图、详细设计的程序流程图和数据库表结构，并对征订、库存、购买、收款四类核心信息表给出字段约束，还介绍了黑盒与白盒测试方法及典型测试用例。资源为单个docx文档，共1份文件，大小651KB，结构完整，便于直接阅读或按章节摘录。目前已有686人学习下载，适合作为课程设计报告撰写、数据库建表及功能流程设计的参考。
1. 教材征订管理系统：一个数据库课程设计为什么值得认真做
每年期末，数据库课程设计选题里总少不了“教材征订管理系统”这个名字。听起来平淡，却是少数能把数据库课里几乎所有核心知识点串起来的题目：ER模型、三范式、外键约束、事务、并发控制、索引优化，全都能落在一个可运行的系统里。但绝大多数人把它做成了“一张登录页加三张表和几个下拉框”，答辩时被问一句“你这订单表有没有考虑并发”就卡壳。本文就把这个题目按最稳妥的工程路径拆开讲清——从建库、写DDL、造数据，到用JDBC把增删改查写成闭环，再到事务和并发锁怎么调，最后给出答辩演示的节奏和加分项。适合选了此题的学生，也适合要带课程设计的助教照着做底线检查。
2. 从需求到ER图：先定边界再建表，教科书没告诉你的取舍
2.1 教材征订的五个核心业务流
做课程设计最容易犯的错是一上来就建表。建表的前提是先把业务边界画出来，否则表结构一定返工。教材征订管理系统最常见的业务流有五条：基础数据维护（班级、学生、教材、课程）、学生提交征订、管理员审核订购、入库与发放、按课程或班级汇总统计。基础数据维护是纯粹的增删改查，学生征订则要处理“一个学生订哪些教材、订几本”，审核环节要控制状态流转，发放环节要扣减库存，最后的统计报表要按教材、班级、学期做分组聚合。
实践中我一般会把边界定在“征订 + 汇总 + 库存扣减”，不碰审批流，也不做复杂的角色权限。原因很现实：课程设计周期一般两到三个月，审批流会让订单表多出大量状态字段和状态机逻辑，而数据库课程的评分重点在关系建模和SQL本身，不在业务复杂度。把“提交征订”这个动作拆开看，它本质是往订单主表和订单明细表各插一条记录，这个动作正好是后面讲事务的最佳载体。如果题目展示里加上了审核状态，也只是多一个update操作，不影响整体设计。
2.2 用MySQL Workbench把ER图落成物理模型
确定业务流之后，下一步是把ER图一层层画出来。我在课设指导里通常建议先画出六到七张核心表：班级表、学生表、教材表、课程表、征订主表、征订明细表。班级和学生是一对多，一个班级有多个学生；学生和征订主表是一对多，一个学生可以有多期征订；征订主表和征订明细表是一对多，一张订单调对应若干条教材明细。至于课程和教材，看起来是多对多——一门课可以用多本教材，一本教材也可能被多门课选用——但课设里为了减少一张关联表，常见做法是课程表里直接加教材ID字段，把多对多降级成一对多，代价是同一本教材被多门课引用时需要重复录数据。建议做ER图时保留多对多关系，建表时再按实际需要决定是否合并。
画ER图这个阶段，我会直接用MySQL Workbench的EER Diagram功能拖表，因为它能从模型直接正向生成DDL脚本，避免手写建表语句时外键方向搞反。字段设计上要注意几点：学生表的学号虽然唯一，但建议仍用自增ID做主键，学号单独加唯一索引，这样学生改名或转学时不会影响关联表；教材的ISBN同理，可以做唯一索引但别当主键。班级表与学院、专业的关系课设里通常不用拆太细，把学院专业直接建成班级表的两个普通字段即可。
2.3 三范式与反范式的取舍：订单明细表该不该冗余教材名
数据库课程设计报告中，范式分析是必写的一块，但实际建表不能机械地逐级遵守范式。以订单明细表为例，第一范式要求字段不可再分，这个必须遵守，不能出现“教材名称、教材作者”堆在一个字段里；第二范式要求非主键字段完全依赖主键，而订单明细表的主键一般是“征订ID + 教材ID”的联合主键，那么“订购数量”这类字段没问题，但“学生姓名”如果放进明细表就只依赖征订ID而不依赖教材ID，这就是违背第二范式。第三范式要求非主键字段之间不能有传递依赖，这里最典型的是明细表里不存“教材单价”，而通过JOIN教材表去取——问题是教材价格会调整，订单里存的是下单时的价格，一旦教材表改价，历史订单统计就错了。
所以反范式在这里是必要的：我在订单明细表里会冗余存“教材名称”和“下单单价”两个字段。虽然技术上违背了第三范式，但这是快照语义——下单那一刻的教材名和价格必须被固定下来，后续教材表怎么改都不影响历史订单。这也是答辩时很加分的分析点：你能说清楚“哪里违反了范式，为什么故意违反”。同理，订单主表里冗余“班级名称”也值得做，否则统计某个班级订了哪些教材时，每次都要从学生表JOIN班级表才能拿到班级名，数据量一大查询就吃亏。反范式的原则只有一个：冗余字段只读不改，由业务代码保证写入时一次写对。
3. 建库与导入：DDL语句、字符集与初始数据的血泪参数
3.1 一套能直接跑的建库建表DDL脚本
ER图画清楚后，建库建表就是把模型翻译成DDL。下面这套脚本是按MySQL 8.x写的InnoDB引擎、utf8mb4字符集，外键约束齐全，可以直接跑在本地MySQL上。
CREATE DATABASE IF NOT EXISTS textbook_order_system DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_0900_ai_ci; USE textbook_order_system; CREATE TABLE class_info ( class_id INT AUTO_INCREMENT PRIMARY KEY, class_name VARCHAR(50) NOT NULL, major_name VARCHAR(50) NOT NULL COMMENT '专业名称', grade_year YEAR NOT NULL COMMENT '入学年份' ) ENGINE=InnoDB COMMENT='班级表'; CREATE TABLE student ( student_id INT AUTO_INCREMENT PRIMARY KEY, student_no VARCHAR(20) NOT NULL COMMENT '学号', student_name VARCHAR(50) NOT NULL, class_id INT NOT NULL, UNIQUE KEY uk_stu_no (student_no), CONSTRAINT fk_stu_class FOREIGN KEY (class_id) REFERENCES class_info (class_id) ) ENGINE=InnoDB COMMENT='学生表'; CREATE TABLE textbook ( textbook_id INT AUTO_INCREMENT PRIMARY KEY, textbook_name VARCHAR(100) NOT NULL, isbn VARCHAR(20) NOT NULL, author VARCHAR(50) NOT NULL, price DECIMAL(6,2) NOT NULL, stock INT NOT NULL DEFAULT 0 COMMENT '当前库存', UNIQUE KEY uk_isbn (isbn) ) ENGINE=InnoDB COMMENT='教材表'; CREATE TABLE course ( course_id INT AUTO_INCREMENT PRIMARY KEY, course_name VARCHAR(50) NOT NULL, textbook_id INT NOT NULL COMMENT '课程关联教材', CONSTRAINT fk_course_textbook FOREIGN KEY (textbook_id) REFERENCES textbook (textbook_id) ) ENGINE=InnoDB COMMENT='课程表'; CREATE TABLE order_master ( order_id INT AUTO_INCREMENT PRIMARY KEY, student_id INT NOT NULL, order_date DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, status TINYINT NOT NULL DEFAULT 0 COMMENT '0已提交 1已发放', total_amount DECIMAL(8,2) NOT NULL DEFAULT 0, CONSTRAINT fk_order_student FOREIGN KEY (student_id) REFERENCES student (student_id) ) ENGINE=InnoDB COMMENT='征订主表'; CREATE TABLE order_detail ( order_id INT NOT NULL, textbook_id INT NOT NULL, quantity INT NOT NULL COMMENT '订购数量', unit_price DECIMAL(6,2) NOT NULL COMMENT '冗余下单单价', textbook_name VARCHAR(100) NOT NULL COMMENT '冗余教材名快照', PRIMARY KEY (order_id, textbook_id), CONSTRAINT fk_detail_order FOREIGN KEY (order_id) REFERENCES order_master (order_id), CONSTRAINT fk_detail_textbook FOREIGN KEY (textbook_id) REFERENCES textbook (textbook_id) ) ENGINE=InnoDB COMMENT='征订明细表';这里几个参数说明一下。utf8mb4_0900_ai_ci是MySQL 8.x的默认排序规则，支持中文排序且大小写不敏感，如果你的MySQL是5.7，改成utf8mb4_general_ci，否则建库语句会直接报未知排序规则。外键命名规范是fk_子表_主表，这个习惯能从约束名直接看出关联关系，后面删错约束时能快速定位。订单明细表用联合主键(order_id, textbook_id)，天然防止同一张订单里重复录入同一本教材，这是通过数据库约束兜底，不依赖前端判断。
3.2 初始数据怎么造：手写SQL太慢，python脚本批量生成
表建好后，课设演示必须有像样的数据，几十条手工INSERT远远不够看。手写SQL造数据效率低到你怀疑人生，尤其是学生表需要几百条时。常见做法是用Python脚本配合pymysql批量插入，数据规律性强，还能控制班级与课程的对应关系。
# generate_data.py import pymysql import random conn = pymysql.connect( host='127.0.0.1', user='root', password='your_password', database='textbook_order_system', charset='utf8mb4' ) cur = conn.cursor() # 插入班级 class_names = [] for grade in ['2022', '2023']: for major in ['软件工程', '计算机科学', '数据科学']: sql = "INSERT INTO class_info (class_name, major_name, grade_year) VALUES (%s, %s, %s)" cur.execute(sql, (major + grade + '班', major, grade)) conn.commit() # 查询班级ID列表，按班级生成学生 cur.execute("SELECT class_id, class_name FROM class_info") class_list = cur.fetchall() for class_id, _ in class_list: for i in range(30): # 每班30人 stu_no = f"{class_id:02d}{i:02d}" # 学号按班级编号拼接 cur.execute( "INSERT INTO student (student_no, student_name, class_id) VALUES (%s, %s, %s)", (stu_no, f"学生{stu_no}", class_id) ) conn.commit() cur.close() conn.close() print("done")造数据时最容易翻车的点是commit时机：如果每插入一条就commit一次，几百条数据会慢到十几秒，正确做法是每满一个逻辑单元（比如一个班级）commit一次，让事务批量提交。学号生成规则要稳定，课设中常见的问题是学号重复导致唯一索引插入失败，这里用class_id + 序号拼接，可以保证唯一性。密码字段如果是必填，应插入固定哈希值而不是明文，虽然课设对安全要求不高，但答辩时老师若看到明文密码直接存库，印象分会打折扣，INSERT ... ON DUPLICATE KEY UPDATE这类写法在造数据阶段没必要用，直接让脚本可重复执行更重要——重复执行前先TRUNCATE TABLE清掉旧数据。
3.3 字符集与排序规则：中文乱码的真相不在前端
中文乱码是建库阶段出现频率最高的翻车现场。大多数人第一反应是改前端页面编码，其实绝大多数情况问题出在两处：一是数据库与表字符集不是utf8mb4，二是JDBC连接串没指定字符集。MySQL 5.7及更早版本的utf8并不是真正的UTF-8，而是utf8mb3，遇到emoji或生僻字会直接报错，所以建库时永远选utf8mb4。第二处坑在JDBC连接串，必须显式追加参数：
jdbc:mysql://127.0.0.1:3306/textbook_order_system ?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai这段参数里useUnicode=true和characterEncoding=utf8必须成对出现，只写其中一个都可能回退到系统默认字符集。serverTimezone=Asia/Shanghai是MySQL 8.x的强制要求，不写会报时区错误，这也是很多人在本地能跑、换到别人的电脑上就启动失败的原因之一。还有一个容易忽略的点：MySQL连接器在5.1.47版本前后对characterEncoding的处理行为有差异，老版本用utf8，新版本用UTF-8也认，最好统一写成utf8。如果你用Navicat这类图形工具导入SQL文件，导入前要在连接属性里确认“使用MySQL字符集”选项，否则文件里写了utf8mb4也可能被工具的本地编码二次转码。判断乱码根因的方法很简单：在命令行客户端直接查这条数据，如果命令行显示正常而应用显示乱码，就是连接层编码问题；如果命令行也乱，那就是库表字符集没建对。
4. 用JDBC把增删改查写活：参数设计决定评分下限
4.1 三层架构下Mapper接口与参数对象设计
很多学生的课设代码把SQL直接写在Servlet或按钮事件里，数据库连接在页面代码中反复创建。这种写法的最大问题不是一个表能查出来，而是当业务要加一个“统计某班某门课教材订了多少本”的功能时，你无处安放这段逻辑。课程设计阶段坚持三层架构很有必要：表现层只负责接收请求和渲染结果，业务层负责事务边界和业务校验，数据访问层只做增删改查。数据访问层的每个方法对应一个Mapper接口，方法参数不能散装成一堆String和Integer，而是用一个参数对象包起来，这样SQL可读性和可维护性都更好。
4.2 PreparedStatement参数绑定：为什么拼接SQL是扣分重灾区
下面的代码演示了正确的新增征订主表和明细表：先插入主表拿到自增订单ID，再循环插入明细表，两条操作包在同一个事务里。
public int addOrder(OrderDTO dto) { String sqlMaster = "INSERT INTO order_master (student_id, total_amount) VALUES (?, ?)"; String sqlDetail = "INSERT INTO order_detail (order_id, textbook_id, quantity, unit_price, textbook_name) " + "VALUES (?, ?, ?, ?, ?)"; Connection conn = null; PreparedStatement psMaster = null; PreparedStatement psDetail = null; try { conn = DriverManager.getConnection(URL, USER, PASSWORD); conn.setAutoCommit(false); // 关闭自动提交，开启事务 psMaster = conn.prepareStatement(sqlMaster, Statement.RETURN_GENERATED_KEYS); psMaster.setInt(1, dto.getStudentId()); psMaster.setBigDecimal(2, dto.getTotalAmount()); int affected = psMaster.executeUpdate(); if (affected != 1) { throw new SQLException("插入征订主表失败"); } ResultSet rs = psMaster.getGeneratedKeys(); int orderId = 0; if (rs.next()) { orderId = rs.getInt(1); } psDetail = conn.prepareStatement(sqlDetail); for (OrderItemDTO item : dto.getItems()) { psDetail.setInt(1, orderId); psDetail.setInt(2, item.getTextbookId()); psDetail.setInt(3, item.getQuantity()); psDetail.setBigDecimal(4, item.getUnitPrice()); psDetail.setString(5, item.getTextbookName()); psDetail.addBatch(); // 加入批处理 } psDetail.executeBatch(); // 一次性执行所有明细插入 conn.commit(); // 提交事务 } catch (SQLException e) { if (conn != null) { try { conn.rollback(); } catch (SQLException ex) { ex.printStackTrace(); } } throw new RuntimeException("征订下单失败", e); } finally { if (psDetail != null) psDetail.close(); if (psMaster != null) psMaster.close(); if (conn != null) conn.close(); } }代码里三个关键点：一是主表插入用Statement.RETURN_GENERATED_KEYS拿到数据库生成的订单ID，不能用SELECT MAX(order_id)去猜测下一条ID，并发下一定会拿重。二是明细插入用addBatch()批处理，几百条明细也能一次发给MySQL，避免单条循环提交频繁网络往返。三是事务边界必须跨主表和明细表，主表插成功、明细插失败时整体回滚，否则会出现“有订单头没有订单行”的脏数据。这套连接管理代码写起来确实啰嗦，课程设计阶段也可以用Spring的JdbcTemplate或MyBatis省掉手写finally关连接的样板代码，但前提是你能解释清楚底层原理，答辩被问“你的事务底层是怎么实现的”时，你得能讲出setAutoCommit(false)和commit/rollback的关系。
4.3 事务边界与并发控制：订同一本教材，两个人同时操作会怎样
事务能解决“一个订单内部的数据一致性”，但解决不了“两个人同时订同一本教材导致的库存超卖”。假设教材库存只剩1本，学生A和学生B同时下单，两个人各自读到库存为1，各自扣减后写回0——看起来没问题，但如果两笔订单都校验“库存充足”而提交时没有加锁，数据库最终结果是库存两次写回，一笔订单超卖。处理方案是在扣库存的SQL里直接做条件更新：
UPDATE textbook SET stock = stock - 1 WHERE textbook_id = ? AND stock >= 1;这行SQL利用的是数据库行锁：两条并发UPDATE同一行时，后到的事务会阻塞等待，直到先到的事务提交或回滚。检查返回值，如果影响行数为0，说明库存不足，订单创建失败回滚。这就是数据库并发锁在课设里最恰当的体现，比在Java代码里加Synchronized靠谱得多——多实例部署时JVM锁是失效的，而行锁是数据库层面保证的。还有一个常见并发事故是死锁：两个事务各自先锁教材A再锁教材B，而另一个事务先锁B再锁A，就可能互相等待。课设数据量小，死锁概率不高，但一旦出现会报Deadlock found when trying to get lock; try restarting transaction，看到这个代码，先在业务层统一加锁顺序，所有事务都先锁ID小的记录，再锁ID大的记录，基本能规避。如果死锁仍存在，可以把MySQL的innodb_lock_wait_timeout从默认的50秒调低到5秒，让事务快速失败而不是长时间挂起，折腾起来至少不那么痛苦。
5. 教材征订系统的常见翻车点：四类高频事故与修复方案
5.1 禁止删除班级时被外键挡住，无法初始化数据
现象：想清空class_info表重新导入数据，执行DELETE FROM class_info直接报错，提示不能删除或更新父行。原因是student表通过外键fk_stu_class引用了class_info，学生表里存在数据时，父表不能随意删行。如果学生表本身没清理干净，常规做法是先删子表再删父表。但课设中更常见的是想整库重置，这时最稳妥的操作是先SET FOREIGN_KEY_CHECKS=0再TRUNCATE多张表，操作完恢复为1。注意TRUNCATE和DELETE的区别：TRUNCATE会重置自增ID，而DELETE不会，重置数据时顺序是明细表、主表、学生表、课程表、教材表、班级表，一张张来才能避开外键约束。
5.2 查询越查越慢：SELECT *加无索引导致全表扫描
现象：学生表几百条数据时查询秒回，数据造到几千条后，按班级查学生需要两三秒，答辩现场很尴尬。原因是SELECT *把所有字段全部查出来，加上WHERE条件是班级ID而无索引。解决办法是两条：查询只选需要的字段，不写星号；给高频条件字段建索引。按班级查学生的场景，student表的class_id字段加索引，效果立竿见影：
ALTER TABLE student ADD INDEX idx_stu_class (class_id);如果查询还涉及按学号精确查找，student_no已有唯一索引uk_stu_no，不用重复建。索引字段选择上有两个原则：一是区分度高的字段优先，二是经常出现在WHERE或JOIN条件里的字段必建。课设里不要为了炫技给每个字段都建索引，索引也是要占用空间的，写入时要额外维护，一个索引都不建的后果是慢，全字段建索引的后果是INSERT和UPDATE变慢，数据量小时感受不到，答辩老师一旦问“为什么这个字段不建索引”，你要能说出理由。
5.3 同一班级同一教材被重复征订，明细表出现两条相同记录
现象：页面连续点两次“提交”，数据库里同一个学生的同一本教材生成了两条明细。原因有两层：第一层是前端没有做按钮防重复提交；第二层是数据库层面没有唯一约束兜底。前端防重复只是体验优化，真正可靠的是数据库约束。如果业务逻辑允许一个学生对同一教材只订一本，那可以在订单明细表和征订主表之间再加一层约束逻辑：在order_detail表上建联合唯一索引(order_id, textbook_id)，这个索引已经由联合主键实现了——上面DDL里主键本身就能挡重复。但如果你在订单明细表用了独立的自增主键，那就必须显式加UNIQUE KEY uk_order_textbook (order_id, textbook_id)。插入前先做一步校验查询也可以，但并发下校验与插入之间存在时间窗口，唯一索引才是最硬的防线。这道题的实质是“重复提交幂等性”，答辩时能讲出“前端防重复是体验，数据库唯一约束是底线”，这个回答足够站稳。
5.4 事务里查询数据读到旧值：隔离级别没理解透
现象：在事务A中先查询某本教材的库存，事务B此时提交了该教材的库存修改，事务A再次查询时发现读到的是修改前的旧值。这个现象在MySQL默认的可重复读隔离级别下完全正常——同一个事务内两次SELECT看到的是同一快照，这恰恰是InnoDB默认隔离级别的设计目标。问题在于学生不理解隔离级别，在业务代码里把“先查库存再扣库存”拆在两个独立查询中，每次查询都是新事务，并发时就读到了旧值。正确的方案就是我们前面说的条件UPDATE，把判断和修改合并成一条原子SQL；如果坚持先查后改，那么SELECT ... FOR UPDATE可以将读取锁定为当前读，阻塞其他事务对该行的写操作，两种方式都能解决，但从性能角度条件UPDATE更优。答辩时把四种隔离级别——读未提交、读已提交、可重复读、串行化——和本系统用的哪一种讲清楚，并说明为什么InnoDB默认可重复读仍然够用，这里就是很明显的加分项。
5.5 数据库连接用后没关，系统运行一晚上后彻底无响应
现象：课设系统上午运行正常，下午开始页面越来越慢，最终报“数据库连接数过多”无法访问。原因是代码里每次执行SQL都新建连接，执行完后没有放进finally块关闭，连接池的连接被耗尽后所有请求排队等待。修复方案分两个层次：如果用的还是最原始的DriverManager.getConnection，那么务必采用try-with-resources写法，让连接在方法结束后自动关闭；更快的方法是引入连接池，比如HikariCP。连接池的核心参数有两个——maximumPoolSize（最大连接数）和minimumIdle（最小空闲连接数），课设场景下maximumPoolSize设10就够，设大了反而浪费内存。另一个常被忽略的参数是connectionTimeout，默认30秒，如果你写的SQL有慢查询，连接获取超时会让用户体验变差，但这个参数不能一味调大，调大了会让故障被掩盖。排查连接泄漏的方法是在连接池配置里开启泄漏检测，HikariCP里对应的是leakDetectionThreshold，超过阈值会打印堆栈告诉你哪段代码拿到的连接没归还，配合日志能快速定位。
6. 答辩前夜：演示数据和两类不显眼但稳过的加分项
6.1 演示脚本：控制演示节奏和关键展示节点
课设答辩最忌讳的是照着代码一行行讲，老师看三分钟就累了。我习惯把演示拆成五步：登入后先展示班级、学生、教材三张基础表，并现场做一次新增教材的操作，同时展示库存字段的变化；第二步提交一笔征订，展示主表和明细表的关联数据；第三步演示库存变化和订单状态的流转；第四步打开统计页面，展示按教材汇总的订购数量和金额；最后展示一条故意构造的错误数据——库存不足时下单被拒绝。整个流程控制在六分钟以内，核心是让老师看到你系统里的数据不是静态摆拍，而是操作后真正变化的。演示数据要提前准备好“演示账号”，并确保连的是本地库而不是测试库，教室里网络环境不稳定，把MySQL连到远程服务器是给自己挖坑——本地演示永远是最稳的。
6.2 加分项：一个视图、一个存储过程、一次成功的死锁恢复
在完成基本增删改查之后，加一个视图能让统计报表的SQL短一半。把“每个班级每种教材的征订人数”包成一个视图，页面查询只需要SELECT * FROM v_class_textbook_order，答辩时一句话就能讲清楚视图的价值是封装复杂JOIN，同时作为安全层隐藏敏感字段。存储过程建议做一个“按教材名统计订购情况”的带参过程，展示IN参数和OUT参数的使用。触发器的加分点在于防止库存负数——在扣库存前校验，如果新库存小于0就抛出异常让事务回滚，这个设计能弥补业务层校验的漏洞。
这两个加分项要适可而止，视图一个就够，存储过程一个就够，触发器做一个就够，别超过两个。答辩老师见过太多“为用存储过程而写存储过程”的学生，本质是把三层架构的逻辑搬到数据库里，反而让维护变难。什么情况下不做加分项？如果你连基本的增删改查和事务都不够稳，别碰这些，老老实实把前面第3章和第4章的代码复述清楚，得分不会差。最后有一句话想留给你：我当年做完这个课设后，把所有DDL脚本和Python造数脚本单独存进了一个db_backup文件夹，后来课程设计提交前一周我误删了数据库，靠着这份脚本半小时内完整恢复了所有演示数据。这个习惯在以后的工作里救了我很多次——数据库永远不是你的本地文件，它是需要备份和能重建的资产。希望这篇写得够细，能帮你少踩几个坑，也希望你能在这个项目中找到比分数更重要的东西——那种把一堆零散的表组织成一个可靠系统的掌控感。
本文还有配套的精品资源，点击获取
