企业官网建设流程全解析

简介：一份面向重庆大学数据库系统课程 Project2 的完整工程包，适合正在完成该课程设计或希望学习数据库系统实现原理的本科生、研究生使用。工程基于 Maven 构建，核心代码以 Java 源码及编译后的 class 文件呈现，配合 Maven 的 XML 配置管理依赖，并内含 JUnit、Calcite 等 jar 库，可直接导入 IDE 运行；压缩包共 51 个文件，除源码与配置外还附有说明文档，整体约 9.92MB，目录结构清晰，便于按模块对照学习。目前已有 64 人浏览/学习，在同类课程作业中具有一定参考价值。整个项目经过严格测试，拿到后即可运行复现；通过阅读源码、测试用例与工程配置，可以快速理解数据库系统的解析、优化或执行等关键模块，并在此基础上扩展二次开发。资源同时涵盖 IDE 工程配置与依赖管理文件，导入 IntelliJ IDEA 等环境即可查看完整结构，适合课程报告、期末大作业、项目实训、学科竞赛等场景。 每年数据库系统课的项目二一发布，压缩包的命名基本都是一个套路：“学校+课程名+project2+日期.zip”。重庆大学版本的这个压缩包，我见过不少同学交上来各种版本，也看过很多人在群里问“里面这些东西到底怎么用”。其实这个项目二，本质就是把数据库设计、SQL编写、JDBC联调、事务处理这一整条链路串起来做一个完整的小型系统，只不过很多同学一上来就被压缩包里的文件结构、环境配置和一堆报错劝退了。

这篇内容我不打算复述什么官方文档，也不讲那种“第一步第二步第三步”的悬浮式教程。我想从拿到zip文件开始，按实际推进项目的路径，把每一环节的关键决策、底层原理和我自己的踩坑经历都摊开讲一遍。无论你是正在写这个project2，还是其他学校的数据库课程项目二，只要任务是“设计数据库+写SQL+用Java/C++/Python连库做功能”，这篇内容都值得你花十分钟看完。

1. 拿到project2.zip的第一天：先别急着写代码

我见过太多人拿到压缩包的第一反应是双击解压，然后立刻打开里面某个代码文件开始读，读了一会儿发现看不懂，又去打开SQL脚本，然后陷入“这到底要我做什么”的迷茫。这个顺序是错的。正确的第一步，是把整个压缩包的文件结构理清楚，分清哪些是参考资料、哪些是必须交付的、哪些是老师预先搭好的脚手架。

1.1 解压之后先找这三类文件

一个典型的project2.zip里，通常会有下面这些内容，我按优先级排个序：

• 任务书或项目说明（可能是PDF、MD或者一个README文本），这里藏着所有考核点、功能要求和交付形式，不看它等于裸奔上考场。
• SQL脚本，常见命名是schema.sql、init.sql、create.sql这类，里面是建表语句和初始数据，这部分可能是老师给定的，也可能需要你自己设计。
• 代码工程目录，如果是Java项目就是src目录，如果是Python就可能是一堆.py文件。这部分通常是半成品，留好了接口或者TODO注释，需要你补齐业务逻辑。

这三类文件一定要按“任务书 → SQL脚本 → 代码工程”的顺序看。原因很简单：任务书告诉你“做什么”，SQL脚本和代码工程告诉你“已经有什么、要改哪里”。如果反着来，你会在别人已经写好的代码里迷失方向，然后忍不住去删改那些其实不该动的东西。

1.2 环境准备清单：版本匹配比你想的更讲究

这一环节最容易被忽略，但也是后面所有痛苦的根源。我建议你建一个环境清单，逐项核对：

这里面最容易坑人的就是时区参数和驱动版本不匹配。我第一次跑通这个项目时，用的MySQL 8.0.33驱动，连接串里忘了加serverTimezone，结果连接时报了个“The server time zone value ‘�й���׼ʱ��’ is unrecognized”的错，光这个报错就卡了我一下午。所以你如果用的是MySQL 8.x的驱动，连接串里直接把这行参数抄进去：

jdbc:mysql://localhost:3306/project2?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai

至于数据库版本，我个人建议直接用MySQL 8.x。数据库系统概论教材（很多学校用第六版）里讲的一些窗口函数、CTE表达式，在MySQL 8.0里都能直接跑，写SQL阶段会很省事。

2. 把需求拆成能落地的数据模型

project2的数据模型设计是整个项目的地基，地基歪了，后面写多少代码都救不回来。我见过有人拿到任务书之后，连ER图都不画，直接打开编辑器就开始写CREATE TABLE。这种做法不是说一定错，但大概率会在做到一半的时候发现表缺字段、关系理不清，然后反复修改，最后反而更慢。

2.1 从任务书里提炼实体与联系

以典型的“学生选课/图书借阅/订单管理”这类系统为例，任务书里会出现很多名词，你要做的第一件事是把这些名词分类：哪些是实体（需要建表的对象），哪些是属性（实体下面的字段），哪些只是查询条件（不需要单独建表）。

这一步对应的就是教材里ER模型的建模过程：实体用矩形、属性用椭圆、联系用菱形。我当时做project2时习惯先把所有名词写在纸上，然后用连线把关系画出来。这个过程看起来很原始，但它能让你在动手建表前就发现很多问题，比如“一个学生可以选多门课，一门课也可以被多个学生选”这种多对多关系，如果一开始没画清楚，后面必然会出现冗余表或者丢失关联表的问题。

常见的实体和联系不外乎这几种：

• 1对多：一个班级有多个学生，学生表里通过班级ID关联班级表。
• 多对多：学生和课程，需要一个中间表（选课表）来把两者的关系拆成两个1对多。
• 1对1：用户和身份证信息，这种在实际项目中很少被拆成两张表，如果任务书里没有强要求，建议直接合并。

2.2 关系模式设计中的三个决策点

把ER图转换成关系模式的时候，有三个点值得停下来想一想，这三个点也是评分老师喜欢看设计文档时打钩的地方：

第一个决策点：主键用业务字段还是代理主键。比如学生表，可以用学号当主键，也可以加一个自增的id字段当主键。学号是天然的业务主键，看起来很方便，但如果学校规定学号要支持修改（比如学籍调整），那所有引用学号的外键都要跟着改。稳妥做法是加一个自增id作为代理主键，学号做成唯一索引。数据库系统课程项目一般规模不大，两种做法都能跑，但在设计文档里写清你选某一种的理由，会显得你真正理解了这个决策背后的代价。

第二个决策点：外键约束到底开不开。这个很多教材没细讲，但实际工程里特别重要。开了外键约束，数据一致性有保障，但插入和删除时要做额外检查，而且删除父表记录时会受到子表限制。对于project2这种课程项目，我建议把外键约束开着，因为任务书考核点里大概率会有“验证数据完整性”这一项，开着外键能帮你应付演示时的提问：“怎么保证选课记录里不会出现不存在的学生？”

第三个决策点：第三范式要不要遵守。教科书上讲BCNF、第三范式讲得很严肃，但实际项目里完全守范式的代价很大。比如订单表里，按范式设计应该只存用户ID，查用户名时要连用户表；但如果你有一个功能模块是查订单列表并显示用户名，连表查询写起来就绕了一层。project2的任务书一般不会强制要求反范式，但如果你愿意在订单表里多存一个“下单时用户名”字段，然后在设计文档里说明这是为了“降低高频查询的连表开销”，这种处理在评分时是可以加分的。

2.3 物理设计与索引取舍

数据模型设计完了就是建表吗？还差一步：物理层面的设计。这一步要做两件事：定字符集、定索引。

字符集不用多说，直接utf8mb4。索引才是值得花心思的地方。你不需要给每个字段都建索引，那会拖慢插入速度。优先考虑三类字段：一是作为查询条件的字段，比如“按课程名称查成绩”，那课程表里的名称字段适合建索引；二是经常被排序的字段，比如按时间字段倒序查最新记录；三是外键字段，因为外键关联时数据库要按外键值去子表查，没索引会很慢。

有一个典型的反例：网上很多建表教程里，会在订单表的“状态”字段上建一个普通索引。但如果这个字段只有三五个取值（待支付、已支付、已发货、已完成），那索引的选择性太差，数据库根本不会用它，反而白白占用空间。这种字段真的不需要索引，或者最多做复合索引的最后一列。设计索引时想清楚“这个字段到底是不是SQL的过滤条件”，比盲目建索引重要得多。

3. 建表与初始化数据：很多人在这里翻车

到了写CREATE TABLE这一步，你可能会觉得终于进入正题了。但实际上这里是最容易被扣分的环节之一。我之前帮学弟学妹做代码Review，发现大家的建表语句普遍存在三个问题：外键依赖顺序不对、约束不完整、初始化数据数量太少。

3.1 建表语句的执行顺序有硬性要求

只要开了外键约束，建表顺序就必须遵循依赖关系。也就是说，先建被引用的表，再建引用别人的表。比如你有一个院系表和一个学生表，学生表外键指向院系表，那必须先执行CREATE TABLE院系，再CREATE TABLE学生。如果你按“想到哪建到哪”的顺序来，大概率会报错：

ERROR 1215 (HY000): Cannot add foreign key constraint

解决这个报错的思路有两个：一是严格按照依赖顺序执行，二是先不写外键约束，等全部表建完之后用ALTER TABLE把外键补上。我个人的习惯是第一种，因为建表脚本本身就承载了“记录表结构”的职责，把外键关系放在CREATE TABLE里，后续维护的人只看这一个文件就明白表之间的关系，不用来回找ALTER语句。

另外，如果要重新建表，你还需要想清楚删除顺序。有外键关系的表，删除顺序和建表顺序相反：先删子表，再删父表。很多同学图省事，用一句DROP TABLE把所有表名全部列出来，结果报错提示外键约束导致无法删除。一个实用的技巧是在建表脚本的开头加一段：

SET FOREIGN_KEY_CHECKS = 0; DROP TABLE IF EXISTS 所有表名; SET FOREIGN_KEY_CHECKS = 1;

这个写法放在本地开发环境没问题，但如果你要提交给老师做自动化评测，最好还是把外键检查开关的语句去掉，或者脚本里严格按依赖顺序DROP，毕竟自动化评测脚本不一定允许你关闭约束检查。

3.2 约束定义得越细，后面代码越省心

很多同学建表只写字段名和类型，主键一标就完事了。这样做在前期写SQL时确实没什么感觉，但等你做JDBC联调时，就会发现程序里需要大量判断空值、重复值，代码写得又臭又长。问题出在建表时没把约束定义完整。

我建议每个字段都问自己几个问题：这个字段能不能为空？有没有默认值？取值范围是什么？有没有唯一性要求？例如用户表里的邮箱字段，如果业务上要求一个邮箱只能注册一个账号，那就直接加上UNIQUE约束，应用层就不用写一遍查重了。学生表里的性别字段，如果只允许“男/女/其他”，可以用ENUM或者CHECK约束（MySQL 8.0.16之后CHECK才真正生效）。这类约束写在数据库里，比写在Java代码里靠谱得多，因为任何入口的数据写入都会被统一拦截。

3.3 初始化数据：数量太少会坑死自己

project2的交付物里，通常要求附带初始化数据，用于演示。但很多同学测试时只用三四条数据，看起来功能都能跑，等到验收时老师随口说一句“你给我查一下选课人数超过3人的课程”，才发现自己的SQL在真实数据下性能惨不忍睹，或者聚合结果根本不对。

造测试数据是有诀窍的。第一，数据量往多了造，每个核心表至少百条以上，关联表（比如选课记录）造到千条级别，这样写聚合查询、分组统计时才有真实感。第二，数据要模拟真实分布，比如学生分布在多个班级而不是集中在某一个班级，课程要有热门和冷门的区分。第三，可以考虑用存储过程或者脚本批量随机生成数据，但要注意随机生成的数据更有可能踩到边界条件，比如同一天多笔订单、同一学生多次退选，这些恰恰是测试SQL逻辑的好用例。

4. 核心SQL与存储过程的取舍

数据模型和初始数据搞定后，就进入SQL编写阶段了。project2对SQL的要求通常集中在几种场景：多表连接查询、分组聚合统计、子查询或视图、触发器或存储过程。这个阶段不需要把任务书里的每个功能平均用力，我按实际评分权重给你做个参考。

4.1 多表连接与分组聚合是绝对主力

数据库系统概论第六版的SQL章节里，连接查询和分组查询是重点中的重点，project2的考核绝大多数也落在这里。典型的需求是“查询每门课程的选课人数，并按人数降序排列”，对应的SQL长这样：

SELECT c.course_id, c.course_name, COUNT(sc.student_id) AS cnt FROM course c LEFT JOIN student_course sc ON c.course_id = sc.course_id GROUP BY c.course_id, c.course_name ORDER BY cnt DESC;

有两个地方要特别注意。第一，JOIN类型选对。如果你用INNER JOIN，那些“没有学生选的课程”就被过滤掉了，但如果需求是“每门课程的选课人数，包括没人选的课”，就必须用LEFT JOIN，让没匹配上的课程也在结果里保留，COUNT是0。第二，SELECT后面出现的非聚合字段（course_id、course_name）要出现在GROUP BY里，否则在ONLY_FULL_GROUP_BY模式（MySQL 5.7.5+默认开启）下会直接报错。这个错误非常常见，几乎所有同学在写分组的SQL时都踩过。

如果任务书里再难一点，会考HAVING和WHERE的区别。简单说，WHERE是在分组前过滤行，HAVING是在分组后过滤分组。比如“查询选课人数超过10人的课程”，这个“10人”是分组之后才能得到的数量，所以只能放在HAVING里。SQL的执行顺序是：FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY，这一条记牢了，写复杂查询时就能避免很多逻辑错误。

4.2 视图、触发器、存储过程：能用但别滥用

project2的加分项往往包括视图、触发器和存储过程。我见过有些同学为了展示技术水平，一口气建了十几个触发器，结果程序一插入数据就触发一堆连锁操作，最后数据被改得面目全非。这其实是没搞清楚触发器的定位。

触发器适合做“一定会在写入时发生的”逻辑，比如写日志、维护统计字段。一个典型场景：选课表里每插入一条选课记录，课程表的已选人数自动加1。这个用触发器实现确实合适，因为不管你从哪个入口写入，都会触发更新。但如果你的更新逻辑只在特定业务场景下才执行，那写进触发器反而是负担。

存储过程和函数的取舍也类似。如果你的项目里有一段SQL要在多个地方复用，比如“根据学生ID查询成绩单”，写成存储过程或函数会清爽很多。但如果只是一次性查询，就没必要为了封装而封装。评判标准就一条：这个SQL会不会被多处重复调用？会，就封装；不会，直接写在JDBC代码里。

4.3 相关子查询与EXISTS的实战场景

project2的高阶SQL里，可能会考相关子查询。这里有个常见的误区：用EXISTS还是IN。教材上会告诉你两种都能实现“包含”语义，但实际性能差别很大。如果子查询的结果集很大，而外层表较小，IN的写法性能往往更差；反过来，如果子查询的结果集很小，IN就够用。在MySQL 8.0里，优化器其实做了很多改写，但这个基本判断原则仍然适用。

一个经典场景是“查询没有选过任何课程的学生”：

SELECT s.student_id, s.student_name FROM student s WHERE NOT EXISTS ( SELECT 1 FROM student_course sc WHERE sc.student_id = s.student_id );

这里用相关子查询，对每个学生到选课表里查一遍有没有记录。数据量小的时候感觉不出来，数据量一大，你就会发现这个SQL会遍历外层表，然后对每个学生执行一次内层查询。但只要你给student_course表的student_id建立了索引，这个写法的性能在课程项目的数据规模下完全够用。

5. JDBC联调与事务处理

SQL写好了，下一步就是通过代码去调用它。如果你们的project2要求用Java+JDBC来做，那这一章的内容你要重点看；如果用的是Python、C++或者其他语言，核心思想也类似，只是API不同。

5.1 JDBC连接代码的规范写法

网上能找到的JDBC连接示例，九成都是把Connection、Statement、ResultSet混在一个方法里，用完不关连接，只在main函数里跑一下。这种代码在课程项目里能跑，但代码审查时非常容易被挑毛病。

规范的做法是：写一个专门的数据库工具类，负责加载驱动、获取连接、关闭资源。最简单的模板长这样：

public class DBUtil { private static final String URL = "jdbc:mysql://localhost:3306/project2?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai"; private static final String USER = "root"; private static final String PASSWORD = "your_password"; static { try { Class.forName("com.mysql.cj.jdbc.Driver"); } catch (ClassNotFoundException e) { e.printStackTrace(); } } public static Connection getConnection() throws SQLException { return DriverManager.getConnection(URL, USER, PASSWORD); } }

这里Class.forName的作用是加载驱动类到JVM；MySQL 8.x的驱动类名是com.mysql.cj.jdbc.Driver，老版本是com.mysql.jdbc.Driver。如果驱动版本和类名不匹配，运行时会报ClassNotFoundException，排查方法就是确认maven或jar包里的驱动版本。

5.2 PreparedStatement：安全性和性能都靠它

JDBC里执行SQL有两种基础方式：Statement和PreparedStatement。project2的代码里如果出现Statement，大概率会被扣分，原因是SQL注入。

举个例子，登录功能里拼接SQL：

String sql = "SELECT * FROM user WHERE username = '" + username + "' AND password = '" + password + "'";

如果用户输入的用户名是admin' --，那这条SQL就变成了：

SELECT * FROM user WHERE username = 'admin' -- ' AND password = '...'

后面的条件被注释掉，攻击者不需要密码就能登录。PreparedStatement之所以安全，是因为它把SQL结构和参数分开了，先让数据库编译SQL模板，再把参数以纯数据的方式传进去，参数里的任何引号都不会被当成SQL语法。写法如下：

String sql = "SELECT * FROM user WHERE username = ? AND password = ?"; PreparedStatement ps = conn.prepareStatement(sql); ps.setString(1, username); ps.setString(2, password); ResultSet rs = ps.executeQuery();

除了安全性，PreparedStatement还有预编译优化。同一段SQL执行多次时，数据库可以复用执行计划，性能比Statement高。所以不管从哪个角度看，都应当用PreparedStatement。

5.3 事务边界：什么时候commit，什么时候rollback

project2的业务场景里，一定有几个操作需要事务保证。典型的就是“学生退课”：要从选课表里删除记录，又要把课程表的已选人数减一。这两步要么都成功，要么都失败。如果在第一步删除之后、第二步更新之前程序崩溃了，数据就处于不一致状态。

JDBC默认是自动提交模式，也就是说每条SQL执行结束后立即提交。要手工控制事务，得先把自动提交关掉：

Connection conn = DBUtil.getConnection(); try { conn.setAutoCommit(false); // 第一步：从选课表删除 String sql1 = "DELETE FROM student_course WHERE student_id = ? AND course_id = ?"; PreparedStatement ps1 = conn.prepareStatement(sql1); ps1.setString(1, studentId); ps1.setString(2, courseId); ps1.executeUpdate(); // 第二步：课程表选课人数减一 String sql2 = "UPDATE course SET selected_count = selected_count - 1 WHERE course_id = ?"; PreparedStatement ps2 = conn.prepareStatement(sql2); ps2.setString(1, courseId); ps2.executeUpdate(); conn.commit(); } catch (SQLException e) { conn.rollback(); e.printStackTrace(); } finally { conn.setAutoCommit(true); conn.close(); }

这里有个容易被忽略的细节：事务隔离级别。数据库系统概论里讲到多个事务并发访问时会遇到脏读、不可重复读、幻读问题，而这取决于隔离级别。MySQL默认的隔离级别是REPEATABLE READ，这个级别能避免脏读和不可重复读，但对幻读只是部分解决。如果你在project2里做并发演示，发现两个事务同时操作同一张表时结果和自己预期不一致，优先检查是否有事务一直没提交，导致另一个事务读到了旧数据快照。

还有一点，事务里如果锁了行，后面又忘了提交，很容易造成死锁或锁等待超时。有一个排查技巧：本地如果出现Lock wait timeout exceeded这个报错，执行下面这条SQL查一下当前有哪些事务在跑：

SELECT * FROM information_schema.INNODB_TRX\G

看看trx_state字段是不是RUNNING，在开发阶段如果发现事务挂着不结束，大概率就是代码里漏了commit或者rollback。

6. 从本地跑通到验收演示：踩坑实录与查漏补缺清单

最后一程，不是代码写完就万事大吉了。我见过太多人本地跑得飞起，一到验收现场就翻车。翻车的原因大多是环境差异、数据量差异、操作顺序差异。这一节我把自己和身边人踩过的坑集中列一下，当做一份查漏补缺的清单。

6.1 时区、字符集、中文乱码的连锁反应

如果验收现场的数据库版本和你本地不一致，第一个炸掉的往往是中文数据。核心检查点有三个：数据库本身的字符集是utf8mb4，表的字符集是utf8mb4，连接串里指定了characterEncoding=utf8。这三者缺一不可。

另一个常见问题是在Windows下用cmd窗口执行SQL脚本，因为cmd默认代码页是GBK，如果你把含有中文的脚本用UTF-8编码保存，然后在cmd里用source命令导入，就会出现乱码。解决方法是执行SQL脚本前先执行：chcp 65001，把代码页切到UTF-8；或者直接用Navicat/DBeaver这类图形化工具导入脚本，它们对编码的处理通常更省心。

6.2 大数据量下的慢查询处理

验收演示时，老师有可能直接在数据量比较大的表上跑复杂查询，这时候如果响应特别慢，场面会很尴尬。解决慢查询的思路很清晰：先定位慢SQL，再针对性优化。

MySQL里可以开启慢查询日志，也可以直接在客户端执行EXPLAIN来查看执行计划：

EXPLAIN SELECT ...;

重点关注type列。如果出现ALL，说明是全表扫描，大概率缺索引；如果是ref或range，说明走了索引，一般问题不大。还有一个值是rows，它表示预估扫描行数，你理想的情况是rows尽量接近最终返回的行数。如果发现某条查询全表扫描且业务上确实高频，那就回到建表脚本里补一个索引，然后在设计文档里把这次优化记录为“根据EXPLAIN结果对查询进行索引优化”。

6.3 并发演示前务必做一次“双开测试”

如果project2要求演示并发场景（比如多人同时抢一门课的剩余名额），有一个必踩的坑就是更新丢失。你可以在本地点开两个终端，同时开启两个事务对同一条记录做更新，观察最终结果。基于“读-改-写”的代码逻辑，大多数情况下结果都会偏离预期。

正确的处理方式是在更新语句里加条件，让更新操作本身具备原子性。比如“课程剩余名额减一”可以写成：

UPDATE course SET remaining = remaining - 1 WHERE course_id = ? AND remaining > 0;

这种方式在数据库层面保证了一旦剩余名额为0，后续更新操作的受影响行数就是0，程序根据update返回的row count判断是否选课成功。这也体现了数据库系统课程里强调的“原子性”和“一致性”在实际代码中的落地：以数据为中心，而不是以程序代码为中心。

6.4 提交前必须走一遍的完整测试路径

最后，我要给一份我在项目二提交前都会走的检查清单，你可以按这个顺序在本地走一遍，确认无误再打包交付：

• 建表脚本能不能在全新的空数据库上完整执行一遍，且不报错。
• 初始化数据是否足够覆盖所有查询场景，每条SQL查询都有返回结果。
• 所有JDBC功能是否在“关闭数据库服务→重启服务”后仍然正常工作，排除依赖缓存假跑的代码。
• 在同一套代码下换一个端口或换一个数据库实例，能否通过修改配置文件实现切换，而不是改动源代码。
• 事务相关操作是否做了异常测试，比如人为制造第二步SQL报错，观察第一步是否被正确回滚。
• 代码里是否有资源泄漏，所有Connection、Statement、ResultSet是否在finally块或try-with-resources中关闭。

以上六项，只要有任意一项不过关，都可能成为验收现场扣分的理由。我见过有人因为建表脚本里一个分号没写，导致老师现场导入时屡屡报错，最后手忙脚乱。这种问题不是技术难度问题，纯粹是缺少“打包前自查”这一步。

说到底，project2这个压缩包考察的从来不只是“你会不会写SQL”，而是你能否从头到尾把一个数据库应用从零落地，并让它稳定运行。这一点想明白了，你的项目二通关之路就顺了一半。

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