简介面向数据库课程设计的小型超市管理系统完整项目工程涵盖前端界面、后端业务逻辑与数据库脚本可满足课程设计、毕业设计、期末大作业及工程实训等场景解决缺少可运行完整项目的痛点。源码经严格测试运行功能稳定支持复现复刻设计报告亦可直接参考便于在此基础上扩展更多功能。压缩包内含369个文件整体约68.62MB主要文件类型包括54个Java后端源码、43个Vue前端组件、71个JavaScript脚本、100个SVG图标以及CSS/SCSS样式、SQL脚本、XML配置和说明文档等目录结构清晰便于按模块查阅与二次开发。目前已有50人学习下载项目答辩评审平均分达96分质量有保障。下载后可获得完整源码、工程文件及配套说明使用过程中如遇问题可联系作者获取帮助适合学生项目练手与开发者学习参考。1. 数据库课设「小型超市管理系统」到底在交什么「数据库课设--小型超市管理系统.zip」这类压缩包每年课程设计季都会在同学之间反复流传。题目看起来不复杂建几张表写一个界面把商品和库存管起来。但真正想把这门课设做好要过的关是「业务能不能闭环、事务能不能保证、答辩能不能自圆其说」。这篇笔记不替你解压任何陌生代码包只讲这个方向最常见的落地路径从业务闭环、ER 图与表结构设计到 MySQL 建库建表、Java 收银事务再到答辩前要避开的几个坑。适合正在做数据库课程设计的人也适合拿到别人工程但想改成自己能讲明白的作品的人。2. 从业务到表结构超市系统先画 ER 图再做关系模式2.1 小型超市的最小业务闭环进货—库存—收银—结算小型超市管理系统拆到底日常业务就四条主线进货、入库、收银、结算。店长从供应商进货生成进货单货到之后变成库存顾客买单时收银台生成销售单同时扣减对应商品库存到了晚上或者月底再按销售单结算营业额。我设计表结构之前一定先把这四条主线画成一张流程草图而不是一上来就开 SQL 编辑器。流程草图上需要标注的实体也很稳定商品、供应商、进货主单、进货明细、销售主单、销售明细、库存流水。实体之间的关系再标一遍一个供应商可以供多种商品一种商品通常也有一个主要供应商一次进货只对应一个供应商但一次进货可以包含很多商品所以进货主单和进货明细是一对多一次收银同理销售主单和销售明细是一对多。这里有一个很容易踩的建模错误把商品表、供应商表、进货表三张表当成完整设计进货单不拆明细。进货单如果不在明细表里拆开就存不下「同一次进 20 种货」的数据销售单如果不拆明细就统计不了单品销量。做课程设计时拆明细带来的工作量不大收益却很高——答辩老师最常问的「哪个商品卖得好、这个月毛利多少」全都靠明细表回答。除此之外ER 图上还有一个容易被忽略的决定主键策略。条码看着像天然主键但超市里的商品可能改条码、换包装会出现一物多码或一码多物的情况。我宁可给商品表一个自增整型主键把条码做成唯一索引。这样业务层可以按条码查商品底层自增主键做外键引用两边都不耽误。2.2 五张核心表的字段设计与主外键关系实体和关系定了之后就可以把 ER 图转成关系模式。以下是我做小型超市管理系统时最常用的一套核心表设计字段尽可能精简方便课程设计里手写 SQL 和代码。商品表 product 的字段id 自增主键barcode 条码唯一索引name 商品名称category 分类supplier_id 外键指向供应商purchase_price 进价sale_price 售价stock_qty 当前库存status 上下架状态。供应商表 supplier 的字段id、name、contact、phone。进货主单 purchase_order 的字段id、supplier_id、order_no、total_amount、created_at。进货明细 purchase_item 的字段id、purchase_order_id、product_id、quantity、unit_price。销售主单 sale_order 和销售明细 sale_item 的结构与进货侧对称。库存流水 inventory_log 记录每一次库存变动的来龙去脉。表外键字段指向productsupplier_idsupplier.idpurchase_ordersupplier_idsupplier.idpurchase_itempurchase_order_id / product_idpurchase_order.id / product.idsale_itemsale_order_id / product_idsale_order.id / product.idinventory_logproduct_idproduct.id这套关系里有两个细节值得注意。第一个是「价格快照」purchase_item.unit_price 和 sale_item.unit_price 在订单生成的瞬间把当时的进价、售价抄进来而不是 JOIN 商品表实时取价。商品改价是常事如果报表回头统计历史销售记录时还要连商品表取价一旦改过价格历史营业额就跟着变了答辩时被问到「这个月毛利怎么算的」会很难解释。第二个是「业务单号」order_no 和自增 id 是两回事。id 是内部主键order_no 是要打印在小票上的单号通常用日期加序号生成唯一索引防重复即可。2.3 关系模式规范化和反规范化的取舍库存字段到底该不该存数据库课设老师多半会问「你的表满足第几范式」。按 ER 图拆主单和明细基本能到第三范式。但商品表里的 stock_qty 这个字段严格来说破坏了第三范式——因为它的值可以由「进货总量 - 销售总量」推导出来。要不要留是小型超市管理系统课设里最值得单独想清楚的设计决策。我的建议是课设场景下一定要留理由不是范式而是查询性能和演示效果。收银界面要实时显示库存如果每次点开商品列表都要 SUM 一遍进销存流水数据量大了会明显变慢演示时转圈很尴尬。留一个 stock_qty 字段每次进货、销售都同步更新它读库存就是一条 UPDATE 加一次 SELECT响应快。留了冗余字段就要保证「推导值 冗余值」。做法是所有库存变化的入口——进货单入库、销售单出库、手动盘点——必须走到同一个更新逻辑里。我一般会在库存流水表里记一条变更记录同时 UPDATE 商品的 stock_qty两步放在同一个事务里。这样即使 stock_qty 被改坏也能通过流水反查找回真实库存。这个事务在第 4 章的收银代码里会具体看到。答辩的时候不要硬说「我绝对第三范式」直接说「我在商品表做了一处反规范化用冗余字段换查询性能并用库存流水保证一致性」。老师能接受因为这证明你既懂范式也懂性能权衡。千万别让库存字段和流水两头算最后对不上那才是真正的翻车现场。3. 用 MySQL 把库建出来建库建表与基础数据的完整命令3.1 建库、字符集与存储引擎选型为什么用 InnoDB utf8mb4我通常用 MySQL 8.0 做这种课设安装简单默认行为也比老版本省心。建库这一步最影响后续体验的两个参数字符集和排序规则。命令如下CREATE DATABASE IF NOT EXISTS supermarket DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_unicode_ci;补充说明utf8mb4 才是完整的四字节 UTF-8 编码能存中文、生僻字、emoji。MySQL 老版本的 utf8 实际最多三字节存 emoji 会报错。排序规则选 utf8mb4_unicode_ci 在课程设计里够用等值查询和普通排序都不受影响。如果你在 Linux 服务器上部署还要确认 SQL 文件本身存成 UTF-8 无 BOMWindows 记事本默认带 BOM可能导致第一行建库语句报错。存储引擎选 InnoDB因为它支持事务、外键约束、行级锁。小型超市收银扣库存是典型的并发写场景MyISAM 不支持事务做到一半断电或异常库存和销售单可能只更新了一个。答辩如果问起存储引擎就把事务和外键两条说清楚顺带说明为什么不能用 MyISAM。建库之后可以用SHOW CREATE DATABASE supermarket;检查字符集是否真的生效这一步能避免后面中文全部变成问号。3.2 建表脚本商品、供应商、进货单、销售单、库存流水进入数据库后按依赖顺序建表先建 supplier再建 product再建进货、销售主表和明细表最后建 inventory_log。完整脚本如下USE supermarket; CREATE TABLE supplier ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, name VARCHAR(100) NOT NULL, contact VARCHAR(50) NOT NULL DEFAULT , phone VARCHAR(20) NOT NULL DEFAULT , created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_supplier_name (name) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE product ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, barcode VARCHAR(32) NOT NULL, name VARCHAR(100) NOT NULL, category VARCHAR(50) NOT NULL DEFAULT , supplier_id INT UNSIGNED DEFAULT NULL COMMENT 主要供应商, purchase_price DECIMAL(10,2) NOT NULL DEFAULT 0.00, sale_price DECIMAL(10,2) NOT NULL DEFAULT 0.00, stock_qty INT NOT NULL DEFAULT 0 COMMENT 当前库存冗余字段, status TINYINT NOT NULL DEFAULT 1 COMMENT 1上架 0下架, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_barcode (barcode), KEY idx_product_supplier (supplier_id), CONSTRAINT fk_product_supplier FOREIGN KEY (supplier_id) REFERENCES supplier(id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE purchase_order ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL, supplier_id INT UNSIGNED NOT NULL, total_amount DECIMAL(10,2) NOT NULL DEFAULT 0.00, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_purchase_order_no (order_no), KEY idx_purchase_supplier (supplier_id), CONSTRAINT fk_purchase_supplier FOREIGN KEY (supplier_id) REFERENCES supplier(id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE purchase_item ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, purchase_order_id INT UNSIGNED NOT NULL, product_id INT UNSIGNED NOT NULL, quantity INT NOT NULL, unit_price DECIMAL(10,2) NOT NULL COMMENT 进货价快照, KEY idx_purchase_item_order (purchase_order_id), KEY idx_purchase_item_product (product_id), CONSTRAINT fk_purchase_item_order FOREIGN KEY (purchase_order_id) REFERENCES purchase_order(id), CONSTRAINT fk_purchase_item_product FOREIGN KEY (product_id) REFERENCES product(id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE sale_order ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL, total_amount DECIMAL(10,2) NOT NULL DEFAULT 0.00, operator VARCHAR(50) NOT NULL DEFAULT , created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_sale_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE sale_item ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, sale_order_id INT UNSIGNED NOT NULL, product_id INT UNSIGNED NOT NULL, quantity INT NOT NULL, unit_price DECIMAL(10,2) NOT NULL COMMENT 售价快照, KEY idx_sale_item_order (sale_order_id), KEY idx_sale_item_product (product_id), CONSTRAINT fk_sale_item_order FOREIGN KEY (sale_order_id) REFERENCES sale_order(id), CONSTRAINT fk_sale_item_product FOREIGN KEY (product_id) REFERENCES product(id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE inventory_log ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, product_id INT UNSIGNED NOT NULL, change_qty INT NOT NULL COMMENT 正数入库负数出库, after_qty INT NOT NULL COMMENT 变动后库存, biz_type VARCHAR(20) NOT NULL COMMENT PURCHASE/SALE/ADJUST, biz_no VARCHAR(64) NOT NULL DEFAULT , created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_inventory_log_product (product_id), CONSTRAINT fk_inventory_log_product FOREIGN KEY (product_id) REFERENCES product(id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;几个参数说明DECIMAL(10,2) 用来存金额不要用 FLOAT否则累计算账会出现 0.1 加 0.2 不等于 0.3 的经典问题。INT UNSIGNED 保证主键和外键不会出现负数。UNIQUE KEY 和普通 KEY 的区别唯一索引约束数据唯一普通索引只加速查询。外键约束会自动要求目标列有索引MySQL 在创建外键时会顺便建一个所以明细表里不需要再重复给同一列建两个索引。这里还要解释为什么 inventory_log 用 BIGINT进出货流水会一直累积课程设计的数据量虽然小但展示项目时总该让答辩老师看到你考虑了增长。另外流水表里的 after_qty 非常关键它记录了每一次变动之后的库存值出了问题可以直接定位是哪一笔把库存改成负数的。3.3 插入测试数据与常用查询收银台最关心的实时库存表建完先插几条货真价实的测试数据别一上来就写业务代码。插入数据本身也是验证约束的过程INSERT INTO supplier (name, contact, phone) VALUES (某供应链公司, 联系人A, 13800000000), (某乳业配送站, 联系人B, 13900000000); INSERT INTO product (barcode, name, category, supplier_id, purchase_price, sale_price, stock_qty) VALUES (690000000001, 原味酸奶, 乳品, 2, 2.50, 3.50, 20), (690000000002, 苏打水, 饮品, 1, 1.80, 2.50, 50), (690000000003, 全麦面包, 食品, 1, 4.00, 6.00, 8);供应商和商品的商品名不要写成真实品牌答辩时用「原味酸奶」「苏打水」这种通用名完全够还避免了商标问题。插入之后跑几个收银台最常用的查询。第一个是库存预警SELECT id, barcode, name, stock_qty FROM product WHERE status 1 AND stock_qty 5;第二个是今日营业额汇总SELECT CAST(created_at AS DATE) AS sale_date, SUM(total_amount) AS total_amount FROM sale_order WHERE created_at CURDATE() GROUP BY CAST(created_at AS DATE);第三个是销量排行SELECT p.name, SUM(si.quantity) AS sold_qty FROM sale_item si JOIN product p ON si.product_id p.id GROUP BY si.product_id, p.name ORDER BY sold_qty DESC LIMIT 10;这三个查询覆盖了小型超市管理系统最重要的三类报表缺货监控、营业日报、单品排行。答辩时演示这三条 SQL比在界面上乱点菜单有说服力。注意CAST(created_at AS DATE)会让查询无法利用 created_at 索引数据量百万以上时会慢课设阶段不用纠结但要在心里知道这个边界。4. 业务层怎么连数据库一个 Java 课设的最小闭环4.1 连接池还是 JDBC 裸连课设场景的取舍课程设计不是企业项目我的原则是「能少一层就少一层」。直接用一个 JDBC 工具类管理连接比引入连接池和 ORM 框架更容易在答辩时讲清楚。连接池是加分项但不是必需品如果演示时只有单机一个客户端访问裸连接完全够用。下面是一个最小可用的数据库连接工具类import java.sql.Connection; import java.sql.DriverManager; public class DBUtil { private static final String URL jdbc:mysql://localhost:3306/supermarket ?useUnicodetruecharacterEncodingutf8 serverTimezoneAsia/Shanghai useSSLfalse allowPublicKeyRetrievaltrue; private static final String USER root; private static final String PASSWORD 123456; public static Connection getConnection() throws Exception { Class.forName(com.mysql.cj.jdbc.Driver); return DriverManager.getConnection(URL, USER, PASSWORD); } }参数逐个说characterEncodingutf8 配合数据库的 utf8mb4能保证中文正常读写serverTimezoneAsia/Shanghai 是 MySQL 8.0 驱动必须的否则会报时区异常useSSLfalse 关闭本地开发证书校验allowPublicKeyRetrievaltrue 解决 MySQL 8.0 默认认证插件偶尔抛出的公钥检索错误。注意密码写死在代码里是课设常见做法但稍微讲究一点可以改成读配置文件这个动作很便宜答辩还能多一句「配置和代码分离」。4.2 事务边界一次收银操作里库存和销售单必须同时成功小型超市管理系统最值得展示的一段代码就是收银时的事务处理。一次完整收银要写四样东西销售主单、销售明细、扣减商品库存、写库存流水。任何一步失败前几步都要废除。下面是一个简化但逻辑完整的收银方法public void checkout(String orderNo, BigDecimal totalAmount, ListSaleItem items) throws Exception { Connection conn DBUtil.getConnection(); try { conn.setAutoCommit(false); // 开启事务 // 1. 写销售主单拿到自增主键 long orderId 0; try (PreparedStatement ps conn.prepareStatement( INSERT INTO sale_order(order_no, total_amount) VALUES (?, ?), Statement.RETURN_GENERATED_KEYS)) { ps.setString(1, orderNo); ps.setBigDecimal(2, totalAmount); ps.executeUpdate(); try (ResultSet rs ps.getGeneratedKeys()) { if (rs.next()) { orderId rs.getLong(1); } } } // 2. 逐商品扣库存、写明细、写库存流水 for (SaleItem item : items) { // 关键一句带库存条件的更新防止超卖 try (PreparedStatement ps conn.prepareStatement( UPDATE product SET stock_qty stock_qty - ? WHERE id ? AND stock_qty ?)) { ps.setInt(1, item.getQuantity()); ps.setInt(2, item.getProductId()); ps.setInt(3, item.getQuantity()); if (ps.executeUpdate() 0) { throw new RuntimeException(库存不足商品ID: item.getProductId()); } } // 写销售明细 try (PreparedStatement ps conn.prepareStatement( INSERT INTO sale_item(sale_order_id, product_id, quantity, unit_price) VALUES (?, ?, ?, ?))) { ps.setLong(1, orderId); ps.setInt(2, item.getProductId()); ps.setInt(3, item.getQuantity()); ps.setBigDecimal(4, item.getUnitPrice()); ps.executeUpdate(); } // 写库存流水after_qty 可按需封装 getStock() 查询 try (PreparedStatement ps conn.prepareStatement( INSERT INTO inventory_log(product_id, change_qty, after_qty, biz_type, biz_no) VALUES (?, ?, ?, SALE, ?))) { ps.setInt(1, item.getProductId()); ps.setInt(2, -item.getQuantity()); ps.setInt(3, 0); // 实际课设里这里查一次商品表填真实值 ps.setString(4, orderNo); ps.executeUpdate(); } } conn.commit(); // 全部成功才提交 } catch (Exception e) { conn.rollback(); // 任何一步失败全部回滚 throw e; } finally { conn.setAutoCommit(true); conn.close(); } }这段代码里最核心的是那条带条件的 UPDATEUPDATE product SET stock_qty stock_qty - ? WHERE id ? AND stock_qty ?。执行结果返回 0 就说明库存不够直接抛异常让整个事务回滚。不要写成「先 SELECT 查库存够再 UPDATE」两个收银台同时操作同一件商品时两次 SELECT 都可能看到库存够最终库存就会变成负数。条件更新在 InnoDB 行锁下会排队执行天然解决了超卖问题。4.3 常见界面方案控制台、Swing、Web 自选业务层写完剩下的问题就是「给用户看什么」。三种常见方案各有取舍按课设时间和答辩要求选界面方案开发工作量演示效果适合场景控制台命令行小一般时间紧张重点展示 SQL 和事务Swing 桌面端中等中传统课设主流无需额外容器Web 页面较大好想做加分项接受前后端代码量我一般选 Swing理由是不需要装 Web 容器双击就能运行演示时不容易被环境问题卡住。Swing 里最常翻车的是把数据库操作直接写在按钮事件线程里导致界面假死改进是不复杂JButton btnPay new JButton(收银); btnPay.addActionListener(e - { try { checkoutService.checkout(orderNo, totalAmount, items); JOptionPane.showMessageDialog(this, 收银成功); refreshTable(); } catch (Exception ex) { JOptionPane.showMessageDialog(this, 收银失败: ex.getMessage()); } });这段代码是课堂作业级别的直接写法胜在短、能跑、答辩好解释。把数据库操作放到 SwingWorker 里可以让界面不卡这是加分项不是必要条件。如果选 Web 方案注意数据库连接不要每个请求都建课程设计用简单的连接池再封装一层就能过。5. 课设答辩常问与避坑指南这些坑我基本都踩过5.1 中文乱码连接串缺了 characterEncoding现象Java 插入的中文在数据库里变成??或者控制台读出来是一堆乱码。原因通常是两层要么连接串没指定字符集要么 SQL 文件本身存成了 GBK 或带 BOM。解决方法是三层对齐数据库建库用 utf8mb4连接串带characterEncodingutf8SQL 源文件存成 UTF-8 无 BOM。自查方式先执行SHOW VARIABLES LIKE character_set_client;再执行一句包含中文的 INSERT 看是否正常不要一上来就改 MySQL 全局配置文件。5.2 外键约束导致删不掉商品现象页面上点了删除商品后端直接抛外键约束失败异常。原因是 sale_item、purchase_item、inventory_log 里已经有这条商品的引用物理删除会被外键拦住。解决思路是换逻辑删除把商品表的 status 置为 0 下架而不是 DELETE。答辩时常有老师追问「那什么时候能物理删除」可以回答在确认没有任何业务单据引用时才物理删除或者做关联清理但业务系统一般保留历史单据逻辑删除更稳妥。用 ON DELETE CASCADE 在这里是错误示范它会连带删掉销售历史查账直接崩。5.3 库存变负数没做事务或没加锁现象演示时库存还剩 3两个收银台各卖 2 件最后库存变成 -1。原因是同一件商品被并发扣减而后台代码是「先查库存够再更新」两步之间数据被另一个请求改掉。解决方法是把扣减写成一条条件 UPDATEUPDATE product SET stock_qty stock_qty - ? WHERE id ? AND stock_qty ?返回值是 0 就说明库存不够直接抛异常回滚。这条语句在 InnoDB 行锁下会排队执行既保证了原子性也没有引入 SELECT FOR UPDATE 的额外复杂度是小型超市管理系统里最实用的一招。5.4 日期时间字段的三种翻车写法现象一插入2026-06-12 14:30:00报错说日期格式不对。原因常见于 Java 里传的是 java.util.Date 而不是 java.sql.Timestamp。解决PreparedStatement.setTimestamp 传 java.sql.Timestamp。现象二数据库里存的时间比本地时间慢 8 小时。原因是连接串缺了serverTimezoneAsia/Shanghai驱动用了服务器默认的 UTC。现象三用WHERE created_at CURDATE()查不到今天的单子。原因是 created_at 是 DATETIME包含时分秒CURDATE() 只有日期。解决日期范围查询写成created_at 2026-06-12 00:00:00 AND created_at 2026-06-13 00:00:00不要用等号匹配日期。5.5 课设报告里最容易被追问的三个点现象答辩时老师不看代码不看界面专盯报告里的设计细节追问。「商品表里这个 stock_qty 不是冗余吗你违反第几范式」「主键用自增以后多门店怎么办」「删除商品为什么不用 DELETE」。原因报告只写了表结构和操作步骤没有写设计理由和权衡这会让老师默认你是抄的。解决报告里专门加一节「设计取舍」把三个问题的答案先写进去。库存字段用库存流水保证一致性自增主键是物理主键条码是唯一索引多门店以后可以加 store_id 再用联合唯一索引删除商品用状态字段做逻辑删除。这节写完答辩时等于提前交了底。6. 把课设做扎实验收清单与一个加分技巧交付前不要只跑一次主流程。我习惯把验收做成一串固定动作在空库上执行一遍建库建表脚本确认无报错从进货、入库、收银、查库存完整跑一遍把某件商品库存改成 1再卖 2 件确认系统会提示库存不足并回滚最后重置演示数据保证下次演示时界面和报表都是确定的结果。整个链路跑两遍没有问题这份课设才算真正完工。加分技巧是给商品表加一个库存预警视图。视图的好处是应用层只需要查询它不用管底层表和预警规则CREATE OR REPLACE VIEW v_inventory_warning AS SELECT barcode, name, category, stock_qty FROM product WHERE status 1 AND stock_qty 5 ORDER BY stock_qty ASC;然后在界面里简单执行SELECT * FROM v_inventory_warning;就能拿到缺货商品列表。这个技巧很轻但能体现三层价值会建视图、知道视图与应用解耦、有预警意识。答辩时顺手说出「改预警阈值只改视图不动业务代码」印象分会明显不一样。最后说句实际经验我早年做课设时最喜欢在界面颜色和按钮布局上下功夫结果有一次演示前忘了重置数据库存和报表全对不上只能硬着头皮说是环境问题。后来我养成两个习惯一是任何数据变更都先备份一份初始化 SQL二是每接一个项目先动手把「建库 → 初始化 → 主流程」跑通再优化别的。做完这个小型超市管理系统你会发现数据库课设真正练的不是建表而是建模前把业务想清楚写代码时把事务守得住。希望帮到你。本文还有配套的精品资源点击获取
简介面向数据库课程设计的小型超市管理系统完整项目工程涵盖前端界面、后端业务逻辑与数据库脚本可满足课程设计、毕业设计、期末大作业及工程实训等场景解决缺少可运行完整项目的痛点。源码经严格测试运行功能稳定支持复现复刻设计报告亦可直接参考便于在此基础上扩展更多功能。压缩包内含369个文件整体约68.62MB主要文件类型包括54个Java后端源码、43个Vue前端组件、71个JavaScript脚本、100个SVG图标以及CSS/SCSS样式、SQL脚本、XML配置和说明文档等目录结构清晰便于按模块查阅与二次开发。目前已有50人学习下载项目答辩评审平均分达96分质量有保障。下载后可获得完整源码、工程文件及配套说明使用过程中如遇问题可联系作者获取帮助适合学生项目练手与开发者学习参考。1. 数据库课设「小型超市管理系统」到底在交什么「数据库课设--小型超市管理系统.zip」这类压缩包每年课程设计季都会在同学之间反复流传。题目看起来不复杂建几张表写一个界面把商品和库存管起来。但真正想把这门课设做好要过的关是「业务能不能闭环、事务能不能保证、答辩能不能自圆其说」。这篇笔记不替你解压任何陌生代码包只讲这个方向最常见的落地路径从业务闭环、ER 图与表结构设计到 MySQL 建库建表、Java 收银事务再到答辩前要避开的几个坑。适合正在做数据库课程设计的人也适合拿到别人工程但想改成自己能讲明白的作品的人。2. 从业务到表结构超市系统先画 ER 图再做关系模式2.1 小型超市的最小业务闭环进货—库存—收银—结算小型超市管理系统拆到底日常业务就四条主线进货、入库、收银、结算。店长从供应商进货生成进货单货到之后变成库存顾客买单时收银台生成销售单同时扣减对应商品库存到了晚上或者月底再按销售单结算营业额。我设计表结构之前一定先把这四条主线画成一张流程草图而不是一上来就开 SQL 编辑器。流程草图上需要标注的实体也很稳定商品、供应商、进货主单、进货明细、销售主单、销售明细、库存流水。实体之间的关系再标一遍一个供应商可以供多种商品一种商品通常也有一个主要供应商一次进货只对应一个供应商但一次进货可以包含很多商品所以进货主单和进货明细是一对多一次收银同理销售主单和销售明细是一对多。这里有一个很容易踩的建模错误把商品表、供应商表、进货表三张表当成完整设计进货单不拆明细。进货单如果不在明细表里拆开就存不下「同一次进 20 种货」的数据销售单如果不拆明细就统计不了单品销量。做课程设计时拆明细带来的工作量不大收益却很高——答辩老师最常问的「哪个商品卖得好、这个月毛利多少」全都靠明细表回答。除此之外ER 图上还有一个容易被忽略的决定主键策略。条码看着像天然主键但超市里的商品可能改条码、换包装会出现一物多码或一码多物的情况。我宁可给商品表一个自增整型主键把条码做成唯一索引。这样业务层可以按条码查商品底层自增主键做外键引用两边都不耽误。2.2 五张核心表的字段设计与主外键关系实体和关系定了之后就可以把 ER 图转成关系模式。以下是我做小型超市管理系统时最常用的一套核心表设计字段尽可能精简方便课程设计里手写 SQL 和代码。商品表 product 的字段id 自增主键barcode 条码唯一索引name 商品名称category 分类supplier_id 外键指向供应商purchase_price 进价sale_price 售价stock_qty 当前库存status 上下架状态。供应商表 supplier 的字段id、name、contact、phone。进货主单 purchase_order 的字段id、supplier_id、order_no、total_amount、created_at。进货明细 purchase_item 的字段id、purchase_order_id、product_id、quantity、unit_price。销售主单 sale_order 和销售明细 sale_item 的结构与进货侧对称。库存流水 inventory_log 记录每一次库存变动的来龙去脉。表外键字段指向productsupplier_idsupplier.idpurchase_ordersupplier_idsupplier.idpurchase_itempurchase_order_id / product_idpurchase_order.id / product.idsale_itemsale_order_id / product_idsale_order.id / product.idinventory_logproduct_idproduct.id这套关系里有两个细节值得注意。第一个是「价格快照」purchase_item.unit_price 和 sale_item.unit_price 在订单生成的瞬间把当时的进价、售价抄进来而不是 JOIN 商品表实时取价。商品改价是常事如果报表回头统计历史销售记录时还要连商品表取价一旦改过价格历史营业额就跟着变了答辩时被问到「这个月毛利怎么算的」会很难解释。第二个是「业务单号」order_no 和自增 id 是两回事。id 是内部主键order_no 是要打印在小票上的单号通常用日期加序号生成唯一索引防重复即可。2.3 关系模式规范化和反规范化的取舍库存字段到底该不该存数据库课设老师多半会问「你的表满足第几范式」。按 ER 图拆主单和明细基本能到第三范式。但商品表里的 stock_qty 这个字段严格来说破坏了第三范式——因为它的值可以由「进货总量 - 销售总量」推导出来。要不要留是小型超市管理系统课设里最值得单独想清楚的设计决策。我的建议是课设场景下一定要留理由不是范式而是查询性能和演示效果。收银界面要实时显示库存如果每次点开商品列表都要 SUM 一遍进销存流水数据量大了会明显变慢演示时转圈很尴尬。留一个 stock_qty 字段每次进货、销售都同步更新它读库存就是一条 UPDATE 加一次 SELECT响应快。留了冗余字段就要保证「推导值 冗余值」。做法是所有库存变化的入口——进货单入库、销售单出库、手动盘点——必须走到同一个更新逻辑里。我一般会在库存流水表里记一条变更记录同时 UPDATE 商品的 stock_qty两步放在同一个事务里。这样即使 stock_qty 被改坏也能通过流水反查找回真实库存。这个事务在第 4 章的收银代码里会具体看到。答辩的时候不要硬说「我绝对第三范式」直接说「我在商品表做了一处反规范化用冗余字段换查询性能并用库存流水保证一致性」。老师能接受因为这证明你既懂范式也懂性能权衡。千万别让库存字段和流水两头算最后对不上那才是真正的翻车现场。3. 用 MySQL 把库建出来建库建表与基础数据的完整命令3.1 建库、字符集与存储引擎选型为什么用 InnoDB utf8mb4我通常用 MySQL 8.0 做这种课设安装简单默认行为也比老版本省心。建库这一步最影响后续体验的两个参数字符集和排序规则。命令如下CREATE DATABASE IF NOT EXISTS supermarket DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_unicode_ci;补充说明utf8mb4 才是完整的四字节 UTF-8 编码能存中文、生僻字、emoji。MySQL 老版本的 utf8 实际最多三字节存 emoji 会报错。排序规则选 utf8mb4_unicode_ci 在课程设计里够用等值查询和普通排序都不受影响。如果你在 Linux 服务器上部署还要确认 SQL 文件本身存成 UTF-8 无 BOMWindows 记事本默认带 BOM可能导致第一行建库语句报错。存储引擎选 InnoDB因为它支持事务、外键约束、行级锁。小型超市收银扣库存是典型的并发写场景MyISAM 不支持事务做到一半断电或异常库存和销售单可能只更新了一个。答辩如果问起存储引擎就把事务和外键两条说清楚顺带说明为什么不能用 MyISAM。建库之后可以用SHOW CREATE DATABASE supermarket;检查字符集是否真的生效这一步能避免后面中文全部变成问号。3.2 建表脚本商品、供应商、进货单、销售单、库存流水进入数据库后按依赖顺序建表先建 supplier再建 product再建进货、销售主表和明细表最后建 inventory_log。完整脚本如下USE supermarket; CREATE TABLE supplier ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, name VARCHAR(100) NOT NULL, contact VARCHAR(50) NOT NULL DEFAULT , phone VARCHAR(20) NOT NULL DEFAULT , created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_supplier_name (name) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE product ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, barcode VARCHAR(32) NOT NULL, name VARCHAR(100) NOT NULL, category VARCHAR(50) NOT NULL DEFAULT , supplier_id INT UNSIGNED DEFAULT NULL COMMENT 主要供应商, purchase_price DECIMAL(10,2) NOT NULL DEFAULT 0.00, sale_price DECIMAL(10,2) NOT NULL DEFAULT 0.00, stock_qty INT NOT NULL DEFAULT 0 COMMENT 当前库存冗余字段, status TINYINT NOT NULL DEFAULT 1 COMMENT 1上架 0下架, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_barcode (barcode), KEY idx_product_supplier (supplier_id), CONSTRAINT fk_product_supplier FOREIGN KEY (supplier_id) REFERENCES supplier(id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE purchase_order ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL, supplier_id INT UNSIGNED NOT NULL, total_amount DECIMAL(10,2) NOT NULL DEFAULT 0.00, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_purchase_order_no (order_no), KEY idx_purchase_supplier (supplier_id), CONSTRAINT fk_purchase_supplier FOREIGN KEY (supplier_id) REFERENCES supplier(id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE purchase_item ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, purchase_order_id INT UNSIGNED NOT NULL, product_id INT UNSIGNED NOT NULL, quantity INT NOT NULL, unit_price DECIMAL(10,2) NOT NULL COMMENT 进货价快照, KEY idx_purchase_item_order (purchase_order_id), KEY idx_purchase_item_product (product_id), CONSTRAINT fk_purchase_item_order FOREIGN KEY (purchase_order_id) REFERENCES purchase_order(id), CONSTRAINT fk_purchase_item_product FOREIGN KEY (product_id) REFERENCES product(id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE sale_order ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL, total_amount DECIMAL(10,2) NOT NULL DEFAULT 0.00, operator VARCHAR(50) NOT NULL DEFAULT , created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_sale_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE sale_item ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, sale_order_id INT UNSIGNED NOT NULL, product_id INT UNSIGNED NOT NULL, quantity INT NOT NULL, unit_price DECIMAL(10,2) NOT NULL COMMENT 售价快照, KEY idx_sale_item_order (sale_order_id), KEY idx_sale_item_product (product_id), CONSTRAINT fk_sale_item_order FOREIGN KEY (sale_order_id) REFERENCES sale_order(id), CONSTRAINT fk_sale_item_product FOREIGN KEY (product_id) REFERENCES product(id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE inventory_log ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, product_id INT UNSIGNED NOT NULL, change_qty INT NOT NULL COMMENT 正数入库负数出库, after_qty INT NOT NULL COMMENT 变动后库存, biz_type VARCHAR(20) NOT NULL COMMENT PURCHASE/SALE/ADJUST, biz_no VARCHAR(64) NOT NULL DEFAULT , created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_inventory_log_product (product_id), CONSTRAINT fk_inventory_log_product FOREIGN KEY (product_id) REFERENCES product(id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;几个参数说明DECIMAL(10,2) 用来存金额不要用 FLOAT否则累计算账会出现 0.1 加 0.2 不等于 0.3 的经典问题。INT UNSIGNED 保证主键和外键不会出现负数。UNIQUE KEY 和普通 KEY 的区别唯一索引约束数据唯一普通索引只加速查询。外键约束会自动要求目标列有索引MySQL 在创建外键时会顺便建一个所以明细表里不需要再重复给同一列建两个索引。这里还要解释为什么 inventory_log 用 BIGINT进出货流水会一直累积课程设计的数据量虽然小但展示项目时总该让答辩老师看到你考虑了增长。另外流水表里的 after_qty 非常关键它记录了每一次变动之后的库存值出了问题可以直接定位是哪一笔把库存改成负数的。3.3 插入测试数据与常用查询收银台最关心的实时库存表建完先插几条货真价实的测试数据别一上来就写业务代码。插入数据本身也是验证约束的过程INSERT INTO supplier (name, contact, phone) VALUES (某供应链公司, 联系人A, 13800000000), (某乳业配送站, 联系人B, 13900000000); INSERT INTO product (barcode, name, category, supplier_id, purchase_price, sale_price, stock_qty) VALUES (690000000001, 原味酸奶, 乳品, 2, 2.50, 3.50, 20), (690000000002, 苏打水, 饮品, 1, 1.80, 2.50, 50), (690000000003, 全麦面包, 食品, 1, 4.00, 6.00, 8);供应商和商品的商品名不要写成真实品牌答辩时用「原味酸奶」「苏打水」这种通用名完全够还避免了商标问题。插入之后跑几个收银台最常用的查询。第一个是库存预警SELECT id, barcode, name, stock_qty FROM product WHERE status 1 AND stock_qty 5;第二个是今日营业额汇总SELECT CAST(created_at AS DATE) AS sale_date, SUM(total_amount) AS total_amount FROM sale_order WHERE created_at CURDATE() GROUP BY CAST(created_at AS DATE);第三个是销量排行SELECT p.name, SUM(si.quantity) AS sold_qty FROM sale_item si JOIN product p ON si.product_id p.id GROUP BY si.product_id, p.name ORDER BY sold_qty DESC LIMIT 10;这三个查询覆盖了小型超市管理系统最重要的三类报表缺货监控、营业日报、单品排行。答辩时演示这三条 SQL比在界面上乱点菜单有说服力。注意CAST(created_at AS DATE)会让查询无法利用 created_at 索引数据量百万以上时会慢课设阶段不用纠结但要在心里知道这个边界。4. 业务层怎么连数据库一个 Java 课设的最小闭环4.1 连接池还是 JDBC 裸连课设场景的取舍课程设计不是企业项目我的原则是「能少一层就少一层」。直接用一个 JDBC 工具类管理连接比引入连接池和 ORM 框架更容易在答辩时讲清楚。连接池是加分项但不是必需品如果演示时只有单机一个客户端访问裸连接完全够用。下面是一个最小可用的数据库连接工具类import java.sql.Connection; import java.sql.DriverManager; public class DBUtil { private static final String URL jdbc:mysql://localhost:3306/supermarket ?useUnicodetruecharacterEncodingutf8 serverTimezoneAsia/Shanghai useSSLfalse allowPublicKeyRetrievaltrue; private static final String USER root; private static final String PASSWORD 123456; public static Connection getConnection() throws Exception { Class.forName(com.mysql.cj.jdbc.Driver); return DriverManager.getConnection(URL, USER, PASSWORD); } }参数逐个说characterEncodingutf8 配合数据库的 utf8mb4能保证中文正常读写serverTimezoneAsia/Shanghai 是 MySQL 8.0 驱动必须的否则会报时区异常useSSLfalse 关闭本地开发证书校验allowPublicKeyRetrievaltrue 解决 MySQL 8.0 默认认证插件偶尔抛出的公钥检索错误。注意密码写死在代码里是课设常见做法但稍微讲究一点可以改成读配置文件这个动作很便宜答辩还能多一句「配置和代码分离」。4.2 事务边界一次收银操作里库存和销售单必须同时成功小型超市管理系统最值得展示的一段代码就是收银时的事务处理。一次完整收银要写四样东西销售主单、销售明细、扣减商品库存、写库存流水。任何一步失败前几步都要废除。下面是一个简化但逻辑完整的收银方法public void checkout(String orderNo, BigDecimal totalAmount, ListSaleItem items) throws Exception { Connection conn DBUtil.getConnection(); try { conn.setAutoCommit(false); // 开启事务 // 1. 写销售主单拿到自增主键 long orderId 0; try (PreparedStatement ps conn.prepareStatement( INSERT INTO sale_order(order_no, total_amount) VALUES (?, ?), Statement.RETURN_GENERATED_KEYS)) { ps.setString(1, orderNo); ps.setBigDecimal(2, totalAmount); ps.executeUpdate(); try (ResultSet rs ps.getGeneratedKeys()) { if (rs.next()) { orderId rs.getLong(1); } } } // 2. 逐商品扣库存、写明细、写库存流水 for (SaleItem item : items) { // 关键一句带库存条件的更新防止超卖 try (PreparedStatement ps conn.prepareStatement( UPDATE product SET stock_qty stock_qty - ? WHERE id ? AND stock_qty ?)) { ps.setInt(1, item.getQuantity()); ps.setInt(2, item.getProductId()); ps.setInt(3, item.getQuantity()); if (ps.executeUpdate() 0) { throw new RuntimeException(库存不足商品ID: item.getProductId()); } } // 写销售明细 try (PreparedStatement ps conn.prepareStatement( INSERT INTO sale_item(sale_order_id, product_id, quantity, unit_price) VALUES (?, ?, ?, ?))) { ps.setLong(1, orderId); ps.setInt(2, item.getProductId()); ps.setInt(3, item.getQuantity()); ps.setBigDecimal(4, item.getUnitPrice()); ps.executeUpdate(); } // 写库存流水after_qty 可按需封装 getStock() 查询 try (PreparedStatement ps conn.prepareStatement( INSERT INTO inventory_log(product_id, change_qty, after_qty, biz_type, biz_no) VALUES (?, ?, ?, SALE, ?))) { ps.setInt(1, item.getProductId()); ps.setInt(2, -item.getQuantity()); ps.setInt(3, 0); // 实际课设里这里查一次商品表填真实值 ps.setString(4, orderNo); ps.executeUpdate(); } } conn.commit(); // 全部成功才提交 } catch (Exception e) { conn.rollback(); // 任何一步失败全部回滚 throw e; } finally { conn.setAutoCommit(true); conn.close(); } }这段代码里最核心的是那条带条件的 UPDATEUPDATE product SET stock_qty stock_qty - ? WHERE id ? AND stock_qty ?。执行结果返回 0 就说明库存不够直接抛异常让整个事务回滚。不要写成「先 SELECT 查库存够再 UPDATE」两个收银台同时操作同一件商品时两次 SELECT 都可能看到库存够最终库存就会变成负数。条件更新在 InnoDB 行锁下会排队执行天然解决了超卖问题。4.3 常见界面方案控制台、Swing、Web 自选业务层写完剩下的问题就是「给用户看什么」。三种常见方案各有取舍按课设时间和答辩要求选界面方案开发工作量演示效果适合场景控制台命令行小一般时间紧张重点展示 SQL 和事务Swing 桌面端中等中传统课设主流无需额外容器Web 页面较大好想做加分项接受前后端代码量我一般选 Swing理由是不需要装 Web 容器双击就能运行演示时不容易被环境问题卡住。Swing 里最常翻车的是把数据库操作直接写在按钮事件线程里导致界面假死改进是不复杂JButton btnPay new JButton(收银); btnPay.addActionListener(e - { try { checkoutService.checkout(orderNo, totalAmount, items); JOptionPane.showMessageDialog(this, 收银成功); refreshTable(); } catch (Exception ex) { JOptionPane.showMessageDialog(this, 收银失败: ex.getMessage()); } });这段代码是课堂作业级别的直接写法胜在短、能跑、答辩好解释。把数据库操作放到 SwingWorker 里可以让界面不卡这是加分项不是必要条件。如果选 Web 方案注意数据库连接不要每个请求都建课程设计用简单的连接池再封装一层就能过。5. 课设答辩常问与避坑指南这些坑我基本都踩过5.1 中文乱码连接串缺了 characterEncoding现象Java 插入的中文在数据库里变成??或者控制台读出来是一堆乱码。原因通常是两层要么连接串没指定字符集要么 SQL 文件本身存成了 GBK 或带 BOM。解决方法是三层对齐数据库建库用 utf8mb4连接串带characterEncodingutf8SQL 源文件存成 UTF-8 无 BOM。自查方式先执行SHOW VARIABLES LIKE character_set_client;再执行一句包含中文的 INSERT 看是否正常不要一上来就改 MySQL 全局配置文件。5.2 外键约束导致删不掉商品现象页面上点了删除商品后端直接抛外键约束失败异常。原因是 sale_item、purchase_item、inventory_log 里已经有这条商品的引用物理删除会被外键拦住。解决思路是换逻辑删除把商品表的 status 置为 0 下架而不是 DELETE。答辩时常有老师追问「那什么时候能物理删除」可以回答在确认没有任何业务单据引用时才物理删除或者做关联清理但业务系统一般保留历史单据逻辑删除更稳妥。用 ON DELETE CASCADE 在这里是错误示范它会连带删掉销售历史查账直接崩。5.3 库存变负数没做事务或没加锁现象演示时库存还剩 3两个收银台各卖 2 件最后库存变成 -1。原因是同一件商品被并发扣减而后台代码是「先查库存够再更新」两步之间数据被另一个请求改掉。解决方法是把扣减写成一条条件 UPDATEUPDATE product SET stock_qty stock_qty - ? WHERE id ? AND stock_qty ?返回值是 0 就说明库存不够直接抛异常回滚。这条语句在 InnoDB 行锁下会排队执行既保证了原子性也没有引入 SELECT FOR UPDATE 的额外复杂度是小型超市管理系统里最实用的一招。5.4 日期时间字段的三种翻车写法现象一插入2026-06-12 14:30:00报错说日期格式不对。原因常见于 Java 里传的是 java.util.Date 而不是 java.sql.Timestamp。解决PreparedStatement.setTimestamp 传 java.sql.Timestamp。现象二数据库里存的时间比本地时间慢 8 小时。原因是连接串缺了serverTimezoneAsia/Shanghai驱动用了服务器默认的 UTC。现象三用WHERE created_at CURDATE()查不到今天的单子。原因是 created_at 是 DATETIME包含时分秒CURDATE() 只有日期。解决日期范围查询写成created_at 2026-06-12 00:00:00 AND created_at 2026-06-13 00:00:00不要用等号匹配日期。5.5 课设报告里最容易被追问的三个点现象答辩时老师不看代码不看界面专盯报告里的设计细节追问。「商品表里这个 stock_qty 不是冗余吗你违反第几范式」「主键用自增以后多门店怎么办」「删除商品为什么不用 DELETE」。原因报告只写了表结构和操作步骤没有写设计理由和权衡这会让老师默认你是抄的。解决报告里专门加一节「设计取舍」把三个问题的答案先写进去。库存字段用库存流水保证一致性自增主键是物理主键条码是唯一索引多门店以后可以加 store_id 再用联合唯一索引删除商品用状态字段做逻辑删除。这节写完答辩时等于提前交了底。6. 把课设做扎实验收清单与一个加分技巧交付前不要只跑一次主流程。我习惯把验收做成一串固定动作在空库上执行一遍建库建表脚本确认无报错从进货、入库、收银、查库存完整跑一遍把某件商品库存改成 1再卖 2 件确认系统会提示库存不足并回滚最后重置演示数据保证下次演示时界面和报表都是确定的结果。整个链路跑两遍没有问题这份课设才算真正完工。加分技巧是给商品表加一个库存预警视图。视图的好处是应用层只需要查询它不用管底层表和预警规则CREATE OR REPLACE VIEW v_inventory_warning AS SELECT barcode, name, category, stock_qty FROM product WHERE status 1 AND stock_qty 5 ORDER BY stock_qty ASC;然后在界面里简单执行SELECT * FROM v_inventory_warning;就能拿到缺货商品列表。这个技巧很轻但能体现三层价值会建视图、知道视图与应用解耦、有预警意识。答辩时顺手说出「改预警阈值只改视图不动业务代码」印象分会明显不一样。最后说句实际经验我早年做课设时最喜欢在界面颜色和按钮布局上下功夫结果有一次演示前忘了重置数据库存和报表全对不上只能硬着头皮说是环境问题。后来我养成两个习惯一是任何数据变更都先备份一份初始化 SQL二是每接一个项目先动手把「建库 → 初始化 → 主流程」跑通再优化别的。做完这个小型超市管理系统你会发现数据库课设真正练的不是建表而是建模前把业务想清楚写代码时把事务守得住。希望帮到你。本文还有配套的精品资源点击获取
