简介一份基于JSP的网上书店系统毕业设计文档面向计算机相关专业学生及需要完成类似课题的开发者。资源完整覆盖从选题背景、系统可行性研究、需求分析到功能模块划分与数据库结构设计的各阶段内容重点讲解如何运用JSP与MySQL实现图书展示、在线购书、订单处理、后台图书管理等核心模块并对比JSP与ASP在性能、安全性和服务器兼容性上的差异。压缩包内共1个doc文件整体大小1.09MB文档包含中英文摘要、目录、正文及参考文献结构清晰。目前已有352人学习适合用于毕业设计参考、论文写作框架梳理以及JSPMySQL项目实践入门能够帮助读者快速把握同类网上商城系统的开发思路。1. JSP网上书店的切入点三层架构先立住如果把一套毕业设计递到我面前最先翻的不是首页而是订单表和购物车实现。网上书店这种业务注册、查询、加购、下单、库存扣减五步串起来就是一个完整闭环恰好把 JSP、Servlet、JavaBean、JDBC、MySQL 和 Tomcat 全部覆盖。这套系统用的是 Java Web 里最经典的 MVC 分工JSP 负责展示Servlet 接收请求并传参JavaBean 处理业务逻辑MySQL 存数据Tomcat 做容器。对正在做 Java Web 课程设计或毕业设计的人来说这是一个能直接复用的业务底稿对已经转投 SpringBoot 的开发者回头看看纯 JSP 时代怎么组织会话与事务也能更清楚框架替你解决了什么。下面按真实开发顺序从需求拆解到数据库落地再到订单事务和部署验证把这条路走通。2. 需求拆解与模块划分前台购书链路与后台数据维护的边界写代码前最忌直接建表。先回答两个问题谁来用、用到什么程度。这套系统分前台和后台两条线前台是购书链路后台是数据维护链路两者通过 orders 表衔接。2.1 可行性分析里的选型判断技术可行性决定了整个技术栈。原材料对比过 ASP 与 JSP结论是 JSP 能跨平台、适配市场上 85% 的服务器配合 Java 的跨平台特性可以做到一次编写到处运行这在实际部署里确实省事。经济可行性上图书作为标品没有尺码、保质期这类复杂属性库存模型简单适合拿来做完整电商练习。操作可行性则指向界面设计用户登录后能直接浏览、搜索、加购管理员登录后能进后台维护两条入口在登录时就要分流。2.2 前台功能映射到页面与服务前台用户功能拆成六块注册、登录、修改密码与个人信息、图书查询、购买图书、订单查看。查询支持按图书名称、出版社、商品类别三种维度其中名称和出版社走模糊匹配类别走精确匹配。用户中心本质上就是 JSP 个人信息展示页面从 user 表回填真名、性别、电话、地址、邮箱和邮编提交后 update 对应字段。功能页面入口处理逻辑注册user_reg.jspRegServlet 校验用户名重复后 insert user 表登录user_login.jspLoginServlet 比对密码成功写入 session图书查询book_query.jspBookQueryServlet 组装条件 SQL 返回列表购物车cart.jspCartServlet 操作 session 中的 Map订单查看order_list.jspOrderServlet 按 user_id 查订单及明细前台还有一个容易被忽略的模块是销量排行。商品销售排行既能给用户做热销指引也能帮管理员做库存决策。销量数据不需要单独建表直接从 orderdetail 聚合出来SELECT d.book_id, b.book_name, SUM(d.quantity) AS sale_count FROM orderdetail d JOIN books b ON d.book_id b.book_id GROUP BY d.book_id, b.book_name ORDER BY sale_count DESC LIMIT 10;这段 SQL 的逻辑是先按 book_id 聚合订单明细关联 books 表取书名再按销量倒序截取前十条。需要注意 MySQL 5.7 之后的 only_full_group_by 模式要求 GROUP BY 字段与 SELECT 的非聚合字段一致所以 GROUP BY 里同时写了 d.book_id 和 b.book_name否则会直接报错。LIMIT 10 可以根据运营需求调整如果后台要配置展示条数把 10 改成参数即可。2.3 后台功能边界管理端功能是图书管理、图书类型管理、订单管理、用户管理。图书管理包含添加、修改、删除类型管理只做添加和修改订单管理和用户管理都只做查看与删除。删除操作里隐藏着一个约束删除图书前必须确认 orderdetail 是否存在关联记录否则外键约束会拒绝删除。实际项目中更稳妥的做法是不物理删除给 books 加一个 status 字段上下架用状态位控制。库存销量查询是后台一个相对独立的功能按库存量大于、小于和销售量大于、小于四类条件筛选。这一模块的价值在于让管理员能快速发现滞销书和缺货书不需要复杂报表一个条件查询页面足够。3. MySQL 七张表订单、订单明细与外键约束的落地设计数据库是这套系统的地基。表结构设计得合理后期联表查询和事务控制都会顺畅设计得随意购物车提交时就会暴露数据不一致的问题。这套系统按业务闭环补全后需要七张表admin、user、booktype、books、orders、orderdetail、notice。3.1 实体关系与表结构实体间的对应关系很清晰user 与 orders 是一对多一个用户有多张订单orders 与 orderdetail 是一对多一张订单包含多本图书booktype 与 books 是一对多一个分类下有多本图书orderdetail 通过 book_id 关联到 books是明细与图书的多对一。notice 公告表独立存在由管理员维护前台首页读取展示。建表语句可以直接用在 MySQL 5.7 和 8.0 上。books 表是核心商品表字段涵盖图书名称、分类、作者、出版社、封面、简介、库存和价格CREATE TABLE books ( book_id INT PRIMARY KEY AUTO_INCREMENT, book_name VARCHAR(100) NOT NULL, type_id INT, author VARCHAR(50), publish VARCHAR(80), cover VARCHAR(200), intro TEXT, total_num INT DEFAULT 0, remaining_num INT DEFAULT 0, price DECIMAL(10,2), KEY idx_type (type_id) ) ENGINEInnoDB DEFAULT CHARSETutf8;total_num 表示总入库数量remaining_num 表示剩余库存两个字段分开便于计算已销量。price 用 DECIMAL(10,2) 而不是 FLOAT避免浮点精度导致金额计算偏差。cover 字段存封面图片路径不直接入库图片二进制减轻数据库压力。type_id 上建普通索引因为分类是高频查询条件。orders 表记录订单头信息注意表名不能直接用 orderorder 是 MySQL 保留字否则每次查询都要加反引号CREATE TABLE orders ( order_id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, buy_time DATETIME DEFAULT CURRENT_TIMESTAMP, total_price DECIMAL(10,2), content VARCHAR(500), ip VARCHAR(64), is_pay TINYINT DEFAULT 0, is_deliver TINYINT DEFAULT 0, KEY idx_user (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8;buy_time 用 DATETIME 类型DEFAULT CURRENT_TIMESTAMP 让数据库自动写入下单时间应用层不需要再传时间参数。is_pay 和 is_deliver 是状态位0 和 1 表示未支付、已支付、未发货、已发货后续订单管理页面直接按这两个字段筛选。content 字段存的是“书名 x 数量”摘要方便列表页不联表就能展示属于冗余设计。orderdetail 表是订单与图书的关联表也是整个系统里外键最密集的地方CREATE TABLE orderdetail ( detail_id INT PRIMARY KEY AUTO_INCREMENT, order_id INT NOT NULL, book_id INT NOT NULL, quantity INT DEFAULT 1, KEY idx_order (order_id), CONSTRAINT fk_detail_order FOREIGN KEY (order_id) REFERENCES orders(order_id), CONSTRAINT fk_detail_book FOREIGN KEY (book_id) REFERENCES books(book_id) ) ENGINEInnoDB DEFAULT CHARSETutf8;3.2 订单明细为什么要独立成表如果只在 orders 表里存一个总价和商品摘要后续无法回答“某本书卖了多少”这类问题销量排行也就无从谈起。orderdetail 把订单与图书拆成多对多关系quantity 记录每本书的购买数量聚合统计时直接对 quantity 求和即可。外键约束有两个实际作用一是防止插入不存在的 book_id二是删除图书或订单时数据库会拒绝逼着应用层先处理子表数据。不过生产环境里外键会带来锁开销很多团队选择在应用层维护一致性。这套系统保留外键更合理因为它本身的并发行不大外键能让毕业设计的评分老师在数据完整性上直接给分。还有一个细节是价格快照。books 表的价格会变但订单生成后应该按当时价格结算。常见的做法是在 orderdetail 里冗余一个 price 字段下单时把 books 当前价格写进去后续图书调价不影响历史订单。这是合格从业者都会做的设计建议建表时把 price DECIMAL(10,2) 加进 orderdetail避免上线后对账困难。4. 购物车与订单生成Session 存储、事务回滚与库存扣减购物车和订单是整套系统的核心链路也是最容易写崩的两个部分。购物车方案选型、订单金额计算、库存扣减时的一致性处理每个环节都有坑。4.1 购物车放在 Session 还是数据库对于这套系统购物车放 Session 是最务实的选择。不需要登录也能往购物车加书用户决定结算时再要求登录购物车的数据结构用MapInteger, Integerkey 是 book_idvalue 是数量。这样省去一张购物车表也不用处理游客与登录用户的合并逻辑。缺点是换设备购物车就丢但毕业设计的业务场景完全够用。加入购物车的 Servlet 代码核心逻辑如下protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { // 从表单隐藏域读取图书编号 int bookId Integer.parseInt(req.getParameter(bookId)); HttpSession session req.getSession(); MapInteger, Integer cart (MapInteger, Integer) session.getAttribute(cart); if (cart null) { cart new HashMapInteger, Integer(); } // 已存在的图书数量加1不存在的初始化1 Integer count cart.get(bookId); cart.put(bookId, count null ? 1 : count 1); session.setAttribute(cart, cart); resp.sendRedirect(cart.jsp); }这段代码有三个要点。bookId 如果解析失败会抛 NumberFormatException实际项目中应该用 try-catch 包住并回跳图书详情页。count 用 Integer 而不是 int因为 Map.get 返回 null 时自动拆箱会空指针。操作完成后必须重新 setAttribute虽然多数容器里 getAttribute 返回的是同一引用但显式写回去更稳妥。购物车的更新、删除、清空操作本质是对这个 Map 的 put 和 remove操作代码逻辑边界条件加入购物车cart.put(bookId, count 1)已存在则数量加 1修改数量cart.put(bookId, newCount)newCount 小于等于 0 时 remove删除单项cart.remove(bookId)移除后 Map 变空要保留空对象清空session.removeAttribute(cart)提交订单成功后执行4.2 订单生成必须走事务提交订单时不能只 insert 一条订单记录这个动作至少涉及三步写入 orders 表、批量写入 orderdetail 表、扣减 books 表的 remaining_num。任何一步失败前面写入的数据都会变成脏数据所以必须用同一个 Connection 包在一个事务里Connection conn null; try { conn DBUtil.getConnection(); conn.setAutoCommit(false); // 开启事务 // 第一步插入订单头获取自增主键 PreparedStatement psOrder conn.prepareStatement( INSERT INTO orders(user_id, total_price, content, ip) VALUES(?,?,?,?), Statement.RETURN_GENERATED_KEYS); psOrder.setInt(1, userId); psOrder.setDouble(2, totalPrice); psOrder.setString(3, content); psOrder.setString(4, ip); psOrder.executeUpdate(); ResultSet rs psOrder.getGeneratedKeys(); int orderId 0; if (rs.next()) { orderId rs.getInt(1); } // 第二步写订单明细 PreparedStatement psDetail conn.prepareStatement( INSERT INTO orderdetail(order_id, book_id, quantity) VALUES(?,?,?)); // 第三步扣减库存带条件防止超卖 PreparedStatement psStock conn.prepareStatement( UPDATE books SET remaining_num remaining_num - ? WHERE book_id ? AND remaining_num ?); for (Map.EntryInteger, Integer item : cart.entrySet()) { psDetail.setInt(1, orderId); psDetail.setInt(2, item.getKey()); psDetail.setInt(3, item.getValue()); psDetail.executeUpdate(); psStock.setInt(1, item.getValue()); psStock.setInt(2, item.getKey()); psStock.setInt(3, item.getValue()); // 影响行数为0说明库存不足抛异常触发回滚 if (psStock.executeUpdate() 0) { throw new RuntimeException(库存不足: bookId item.getKey()); } } conn.commit(); // 全部成功才提交 session.removeAttribute(cart); // 订单生成后清空购物车 } catch (Exception e) { conn.rollback(); // 任何一步失败整体回滚 throw e; } finally { DBUtil.close(conn); }事务的关键点有三个。第一Statement.RETURN_GENERATED_KEYS 用于获取自增的 order_id这一步很关键后面插入 orderdetail 需要这个值。第二库存扣减的 UPDATE 语句把remaining_num ?写进了 WHERE 条件如果库存不足影响行数是 0程序主动抛异常回滚这比先查询库存再判断更可靠因为查询和更新之间可能被其他请求插入。第三订单金额 totalPrice 必须在服务端根据购物车中的图书重新计算不能信任前端传过来的金额否则改一下请求参数就能以任意价格下单。content 字段的内容可以在事务外先查询一次图书名称按“书名 x 数量”拼成字符串。虽然冗余但订单列表页直接展示 content 可以少一次 join对性能有帮助。4.3 订单列表查询的 JOIN 写法前台订单列表需要同时展示订单号、下单时间、总价以及每本书的名称和数量一条 JOIN 查出来最直接SELECT o.order_id, o.buy_time, o.total_price, b.book_name, d.quantity FROM orders o JOIN orderdetail d ON o.order_id d.order_id JOIN books b ON d.book_id b.book_id WHERE o.user_id ? ORDER BY o.order_id DESC, d.detail_id ASC;这条 SQL 的结果集里同一个 order_id 会出现多行每行对应一本图书。JSP 页面渲染时记录上一次的 order_id如果当前行 order_id 跟上一次不同就输出新的订单块。这样做的好处是只需要一次查询不用在 Servlet 里循环查数据库缺点是结果集需要在内存里重组数据量大时性能会下降。毕业设计场景下订单量有限这个取舍是合理的。5. 后台复用、JSP 编译验证与日常数据维护后台管理功能和前台购物链路相比逻辑更简单但要注意复用。图书管理的添加、修改、删除、列表四种操作可以用同一个 admin_book.jsp 加一个 action 参数区分避免复制四个几乎一样的页面。5.1 一个 JSP 页面处理增删改的写法% String action request.getParameter(action); if (delete.equals(action)) { int bookId Integer.parseInt(request.getParameter(bookId)); BookDAO.delete(bookId); response.sendRedirect(admin_book.jsp); return; } // add 和 update 分别读取表单字段 // 调用 BookDAO.insert() 或 BookDAO.update() %这种写法的核心是用 action 作为分发标识所有操作都走同一个页面代码量最少。BookDAO.delete 内部要先删除 orderdetail 里的关联记录再删除 books 记录否则外键会拦截。如果已经加了 status 字段就更推荐用 update 方式把 status 置为 0避免数据丢失。5.2 Tomcat 部署验证的三个检查点JSP 页面修改后不生效多数时候是 Tomcat 的 work 目录缓存。JSP 第一次被访问时会被翻译成 Java 类再编译实际路径在work/Catalina/localhost/项目名/org/apache/jsp/比如 index_jsp.java。想确认当前生效的代码是不是最新编译版本直接看这个目录下的类文件时间戳。如果页面一直显示旧内容停掉 Tomcat 后删除整个 work 目录再重启。如果看到 JSP 页面里的中文乱码第一优先级检查这三个位置JSP 头部的 pageEncoding、浏览器请求的字符集、MySQL 连接串的 characterEncoding。常见写法是% page languagejava contentTypetext/html; charsetUTF-8 pageEncodingUTF-8 %MySQL 连接串里加上?useUnicodetruecharacterEncodingutf8三个地方保持一致中文基本不会出乱码。另外注意 mysql-connector-java 的 jar 包要放在WEB-INF/lib下不要只加在 IDE 的 Build Path 里否则部署到 Tomcat 后运行时会报 ClassNotFoundException。5.3 上线后的数据备份网上书店的数据一旦跑起来orders 和 user 表就是不可丢失的数据备份命令要第一天就写好mysqldump -u root -p bookstore bookstore_backup.sql恢复时执行mysql -u root -p bookstore bookstore_backup.sqlmysqldump 默认导出表结构和数据备份文件是纯文本 SQL恢复前确认目标库存在。用 crontab 定时每天凌晨执行备份保留最近 7 天的备份文件再配合一次手动模拟恢复验证备份可用性这套系统的运维底线就立住了。本文还有配套的精品资源点击获取
基于JSP的网上书店系统设计与实现：三层架构到订单事务
简介一份基于JSP的网上书店系统毕业设计文档面向计算机相关专业学生及需要完成类似课题的开发者。资源完整覆盖从选题背景、系统可行性研究、需求分析到功能模块划分与数据库结构设计的各阶段内容重点讲解如何运用JSP与MySQL实现图书展示、在线购书、订单处理、后台图书管理等核心模块并对比JSP与ASP在性能、安全性和服务器兼容性上的差异。压缩包内共1个doc文件整体大小1.09MB文档包含中英文摘要、目录、正文及参考文献结构清晰。目前已有352人学习适合用于毕业设计参考、论文写作框架梳理以及JSPMySQL项目实践入门能够帮助读者快速把握同类网上商城系统的开发思路。1. JSP网上书店的切入点三层架构先立住如果把一套毕业设计递到我面前最先翻的不是首页而是订单表和购物车实现。网上书店这种业务注册、查询、加购、下单、库存扣减五步串起来就是一个完整闭环恰好把 JSP、Servlet、JavaBean、JDBC、MySQL 和 Tomcat 全部覆盖。这套系统用的是 Java Web 里最经典的 MVC 分工JSP 负责展示Servlet 接收请求并传参JavaBean 处理业务逻辑MySQL 存数据Tomcat 做容器。对正在做 Java Web 课程设计或毕业设计的人来说这是一个能直接复用的业务底稿对已经转投 SpringBoot 的开发者回头看看纯 JSP 时代怎么组织会话与事务也能更清楚框架替你解决了什么。下面按真实开发顺序从需求拆解到数据库落地再到订单事务和部署验证把这条路走通。2. 需求拆解与模块划分前台购书链路与后台数据维护的边界写代码前最忌直接建表。先回答两个问题谁来用、用到什么程度。这套系统分前台和后台两条线前台是购书链路后台是数据维护链路两者通过 orders 表衔接。2.1 可行性分析里的选型判断技术可行性决定了整个技术栈。原材料对比过 ASP 与 JSP结论是 JSP 能跨平台、适配市场上 85% 的服务器配合 Java 的跨平台特性可以做到一次编写到处运行这在实际部署里确实省事。经济可行性上图书作为标品没有尺码、保质期这类复杂属性库存模型简单适合拿来做完整电商练习。操作可行性则指向界面设计用户登录后能直接浏览、搜索、加购管理员登录后能进后台维护两条入口在登录时就要分流。2.2 前台功能映射到页面与服务前台用户功能拆成六块注册、登录、修改密码与个人信息、图书查询、购买图书、订单查看。查询支持按图书名称、出版社、商品类别三种维度其中名称和出版社走模糊匹配类别走精确匹配。用户中心本质上就是 JSP 个人信息展示页面从 user 表回填真名、性别、电话、地址、邮箱和邮编提交后 update 对应字段。功能页面入口处理逻辑注册user_reg.jspRegServlet 校验用户名重复后 insert user 表登录user_login.jspLoginServlet 比对密码成功写入 session图书查询book_query.jspBookQueryServlet 组装条件 SQL 返回列表购物车cart.jspCartServlet 操作 session 中的 Map订单查看order_list.jspOrderServlet 按 user_id 查订单及明细前台还有一个容易被忽略的模块是销量排行。商品销售排行既能给用户做热销指引也能帮管理员做库存决策。销量数据不需要单独建表直接从 orderdetail 聚合出来SELECT d.book_id, b.book_name, SUM(d.quantity) AS sale_count FROM orderdetail d JOIN books b ON d.book_id b.book_id GROUP BY d.book_id, b.book_name ORDER BY sale_count DESC LIMIT 10;这段 SQL 的逻辑是先按 book_id 聚合订单明细关联 books 表取书名再按销量倒序截取前十条。需要注意 MySQL 5.7 之后的 only_full_group_by 模式要求 GROUP BY 字段与 SELECT 的非聚合字段一致所以 GROUP BY 里同时写了 d.book_id 和 b.book_name否则会直接报错。LIMIT 10 可以根据运营需求调整如果后台要配置展示条数把 10 改成参数即可。2.3 后台功能边界管理端功能是图书管理、图书类型管理、订单管理、用户管理。图书管理包含添加、修改、删除类型管理只做添加和修改订单管理和用户管理都只做查看与删除。删除操作里隐藏着一个约束删除图书前必须确认 orderdetail 是否存在关联记录否则外键约束会拒绝删除。实际项目中更稳妥的做法是不物理删除给 books 加一个 status 字段上下架用状态位控制。库存销量查询是后台一个相对独立的功能按库存量大于、小于和销售量大于、小于四类条件筛选。这一模块的价值在于让管理员能快速发现滞销书和缺货书不需要复杂报表一个条件查询页面足够。3. MySQL 七张表订单、订单明细与外键约束的落地设计数据库是这套系统的地基。表结构设计得合理后期联表查询和事务控制都会顺畅设计得随意购物车提交时就会暴露数据不一致的问题。这套系统按业务闭环补全后需要七张表admin、user、booktype、books、orders、orderdetail、notice。3.1 实体关系与表结构实体间的对应关系很清晰user 与 orders 是一对多一个用户有多张订单orders 与 orderdetail 是一对多一张订单包含多本图书booktype 与 books 是一对多一个分类下有多本图书orderdetail 通过 book_id 关联到 books是明细与图书的多对一。notice 公告表独立存在由管理员维护前台首页读取展示。建表语句可以直接用在 MySQL 5.7 和 8.0 上。books 表是核心商品表字段涵盖图书名称、分类、作者、出版社、封面、简介、库存和价格CREATE TABLE books ( book_id INT PRIMARY KEY AUTO_INCREMENT, book_name VARCHAR(100) NOT NULL, type_id INT, author VARCHAR(50), publish VARCHAR(80), cover VARCHAR(200), intro TEXT, total_num INT DEFAULT 0, remaining_num INT DEFAULT 0, price DECIMAL(10,2), KEY idx_type (type_id) ) ENGINEInnoDB DEFAULT CHARSETutf8;total_num 表示总入库数量remaining_num 表示剩余库存两个字段分开便于计算已销量。price 用 DECIMAL(10,2) 而不是 FLOAT避免浮点精度导致金额计算偏差。cover 字段存封面图片路径不直接入库图片二进制减轻数据库压力。type_id 上建普通索引因为分类是高频查询条件。orders 表记录订单头信息注意表名不能直接用 orderorder 是 MySQL 保留字否则每次查询都要加反引号CREATE TABLE orders ( order_id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, buy_time DATETIME DEFAULT CURRENT_TIMESTAMP, total_price DECIMAL(10,2), content VARCHAR(500), ip VARCHAR(64), is_pay TINYINT DEFAULT 0, is_deliver TINYINT DEFAULT 0, KEY idx_user (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8;buy_time 用 DATETIME 类型DEFAULT CURRENT_TIMESTAMP 让数据库自动写入下单时间应用层不需要再传时间参数。is_pay 和 is_deliver 是状态位0 和 1 表示未支付、已支付、未发货、已发货后续订单管理页面直接按这两个字段筛选。content 字段存的是“书名 x 数量”摘要方便列表页不联表就能展示属于冗余设计。orderdetail 表是订单与图书的关联表也是整个系统里外键最密集的地方CREATE TABLE orderdetail ( detail_id INT PRIMARY KEY AUTO_INCREMENT, order_id INT NOT NULL, book_id INT NOT NULL, quantity INT DEFAULT 1, KEY idx_order (order_id), CONSTRAINT fk_detail_order FOREIGN KEY (order_id) REFERENCES orders(order_id), CONSTRAINT fk_detail_book FOREIGN KEY (book_id) REFERENCES books(book_id) ) ENGINEInnoDB DEFAULT CHARSETutf8;3.2 订单明细为什么要独立成表如果只在 orders 表里存一个总价和商品摘要后续无法回答“某本书卖了多少”这类问题销量排行也就无从谈起。orderdetail 把订单与图书拆成多对多关系quantity 记录每本书的购买数量聚合统计时直接对 quantity 求和即可。外键约束有两个实际作用一是防止插入不存在的 book_id二是删除图书或订单时数据库会拒绝逼着应用层先处理子表数据。不过生产环境里外键会带来锁开销很多团队选择在应用层维护一致性。这套系统保留外键更合理因为它本身的并发行不大外键能让毕业设计的评分老师在数据完整性上直接给分。还有一个细节是价格快照。books 表的价格会变但订单生成后应该按当时价格结算。常见的做法是在 orderdetail 里冗余一个 price 字段下单时把 books 当前价格写进去后续图书调价不影响历史订单。这是合格从业者都会做的设计建议建表时把 price DECIMAL(10,2) 加进 orderdetail避免上线后对账困难。4. 购物车与订单生成Session 存储、事务回滚与库存扣减购物车和订单是整套系统的核心链路也是最容易写崩的两个部分。购物车方案选型、订单金额计算、库存扣减时的一致性处理每个环节都有坑。4.1 购物车放在 Session 还是数据库对于这套系统购物车放 Session 是最务实的选择。不需要登录也能往购物车加书用户决定结算时再要求登录购物车的数据结构用MapInteger, Integerkey 是 book_idvalue 是数量。这样省去一张购物车表也不用处理游客与登录用户的合并逻辑。缺点是换设备购物车就丢但毕业设计的业务场景完全够用。加入购物车的 Servlet 代码核心逻辑如下protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { // 从表单隐藏域读取图书编号 int bookId Integer.parseInt(req.getParameter(bookId)); HttpSession session req.getSession(); MapInteger, Integer cart (MapInteger, Integer) session.getAttribute(cart); if (cart null) { cart new HashMapInteger, Integer(); } // 已存在的图书数量加1不存在的初始化1 Integer count cart.get(bookId); cart.put(bookId, count null ? 1 : count 1); session.setAttribute(cart, cart); resp.sendRedirect(cart.jsp); }这段代码有三个要点。bookId 如果解析失败会抛 NumberFormatException实际项目中应该用 try-catch 包住并回跳图书详情页。count 用 Integer 而不是 int因为 Map.get 返回 null 时自动拆箱会空指针。操作完成后必须重新 setAttribute虽然多数容器里 getAttribute 返回的是同一引用但显式写回去更稳妥。购物车的更新、删除、清空操作本质是对这个 Map 的 put 和 remove操作代码逻辑边界条件加入购物车cart.put(bookId, count 1)已存在则数量加 1修改数量cart.put(bookId, newCount)newCount 小于等于 0 时 remove删除单项cart.remove(bookId)移除后 Map 变空要保留空对象清空session.removeAttribute(cart)提交订单成功后执行4.2 订单生成必须走事务提交订单时不能只 insert 一条订单记录这个动作至少涉及三步写入 orders 表、批量写入 orderdetail 表、扣减 books 表的 remaining_num。任何一步失败前面写入的数据都会变成脏数据所以必须用同一个 Connection 包在一个事务里Connection conn null; try { conn DBUtil.getConnection(); conn.setAutoCommit(false); // 开启事务 // 第一步插入订单头获取自增主键 PreparedStatement psOrder conn.prepareStatement( INSERT INTO orders(user_id, total_price, content, ip) VALUES(?,?,?,?), Statement.RETURN_GENERATED_KEYS); psOrder.setInt(1, userId); psOrder.setDouble(2, totalPrice); psOrder.setString(3, content); psOrder.setString(4, ip); psOrder.executeUpdate(); ResultSet rs psOrder.getGeneratedKeys(); int orderId 0; if (rs.next()) { orderId rs.getInt(1); } // 第二步写订单明细 PreparedStatement psDetail conn.prepareStatement( INSERT INTO orderdetail(order_id, book_id, quantity) VALUES(?,?,?)); // 第三步扣减库存带条件防止超卖 PreparedStatement psStock conn.prepareStatement( UPDATE books SET remaining_num remaining_num - ? WHERE book_id ? AND remaining_num ?); for (Map.EntryInteger, Integer item : cart.entrySet()) { psDetail.setInt(1, orderId); psDetail.setInt(2, item.getKey()); psDetail.setInt(3, item.getValue()); psDetail.executeUpdate(); psStock.setInt(1, item.getValue()); psStock.setInt(2, item.getKey()); psStock.setInt(3, item.getValue()); // 影响行数为0说明库存不足抛异常触发回滚 if (psStock.executeUpdate() 0) { throw new RuntimeException(库存不足: bookId item.getKey()); } } conn.commit(); // 全部成功才提交 session.removeAttribute(cart); // 订单生成后清空购物车 } catch (Exception e) { conn.rollback(); // 任何一步失败整体回滚 throw e; } finally { DBUtil.close(conn); }事务的关键点有三个。第一Statement.RETURN_GENERATED_KEYS 用于获取自增的 order_id这一步很关键后面插入 orderdetail 需要这个值。第二库存扣减的 UPDATE 语句把remaining_num ?写进了 WHERE 条件如果库存不足影响行数是 0程序主动抛异常回滚这比先查询库存再判断更可靠因为查询和更新之间可能被其他请求插入。第三订单金额 totalPrice 必须在服务端根据购物车中的图书重新计算不能信任前端传过来的金额否则改一下请求参数就能以任意价格下单。content 字段的内容可以在事务外先查询一次图书名称按“书名 x 数量”拼成字符串。虽然冗余但订单列表页直接展示 content 可以少一次 join对性能有帮助。4.3 订单列表查询的 JOIN 写法前台订单列表需要同时展示订单号、下单时间、总价以及每本书的名称和数量一条 JOIN 查出来最直接SELECT o.order_id, o.buy_time, o.total_price, b.book_name, d.quantity FROM orders o JOIN orderdetail d ON o.order_id d.order_id JOIN books b ON d.book_id b.book_id WHERE o.user_id ? ORDER BY o.order_id DESC, d.detail_id ASC;这条 SQL 的结果集里同一个 order_id 会出现多行每行对应一本图书。JSP 页面渲染时记录上一次的 order_id如果当前行 order_id 跟上一次不同就输出新的订单块。这样做的好处是只需要一次查询不用在 Servlet 里循环查数据库缺点是结果集需要在内存里重组数据量大时性能会下降。毕业设计场景下订单量有限这个取舍是合理的。5. 后台复用、JSP 编译验证与日常数据维护后台管理功能和前台购物链路相比逻辑更简单但要注意复用。图书管理的添加、修改、删除、列表四种操作可以用同一个 admin_book.jsp 加一个 action 参数区分避免复制四个几乎一样的页面。5.1 一个 JSP 页面处理增删改的写法% String action request.getParameter(action); if (delete.equals(action)) { int bookId Integer.parseInt(request.getParameter(bookId)); BookDAO.delete(bookId); response.sendRedirect(admin_book.jsp); return; } // add 和 update 分别读取表单字段 // 调用 BookDAO.insert() 或 BookDAO.update() %这种写法的核心是用 action 作为分发标识所有操作都走同一个页面代码量最少。BookDAO.delete 内部要先删除 orderdetail 里的关联记录再删除 books 记录否则外键会拦截。如果已经加了 status 字段就更推荐用 update 方式把 status 置为 0避免数据丢失。5.2 Tomcat 部署验证的三个检查点JSP 页面修改后不生效多数时候是 Tomcat 的 work 目录缓存。JSP 第一次被访问时会被翻译成 Java 类再编译实际路径在work/Catalina/localhost/项目名/org/apache/jsp/比如 index_jsp.java。想确认当前生效的代码是不是最新编译版本直接看这个目录下的类文件时间戳。如果页面一直显示旧内容停掉 Tomcat 后删除整个 work 目录再重启。如果看到 JSP 页面里的中文乱码第一优先级检查这三个位置JSP 头部的 pageEncoding、浏览器请求的字符集、MySQL 连接串的 characterEncoding。常见写法是% page languagejava contentTypetext/html; charsetUTF-8 pageEncodingUTF-8 %MySQL 连接串里加上?useUnicodetruecharacterEncodingutf8三个地方保持一致中文基本不会出乱码。另外注意 mysql-connector-java 的 jar 包要放在WEB-INF/lib下不要只加在 IDE 的 Build Path 里否则部署到 Tomcat 后运行时会报 ClassNotFoundException。5.3 上线后的数据备份网上书店的数据一旦跑起来orders 和 user 表就是不可丢失的数据备份命令要第一天就写好mysqldump -u root -p bookstore bookstore_backup.sql恢复时执行mysql -u root -p bookstore bookstore_backup.sqlmysqldump 默认导出表结构和数据备份文件是纯文本 SQL恢复前确认目标库存在。用 crontab 定时每天凌晨执行备份保留最近 7 天的备份文件再配合一次手动模拟恢复验证备份可用性这套系统的运维底线就立住了。本文还有配套的精品资源点击获取
