简介：这份数据库课程设计资源面向高校计算机及相关专业学生，围绕某商店进销存管理系统展开，适合正在完成数据库原理课程设计、需要参考完整案例的学习者。资源包共3个文件，包含1个bak数据库备份、1个sql脚本和1个doc课程设计报告，压缩包约704KB，体量轻便，便于快速导入与查阅。其中sql脚本可用于建库建表与数据初始化，bak文件支持数据库还原，doc文档则完整呈现系统分析与设计报告，涵盖需求分析、数据模型设计、数据库结构定义及安全性与完整性要求等阶段内容。已有6416人学习下载，说明该案例在同类课设中具有较高参考价值。读者可借此理清从社会调查选题、系统需求分析到数据库设计与实现的全流程思路，掌握SQL编程与数据库定义方法，并对照报告结构撰写自己的课程设计文档，适合作为高分课设的参考范本。
1. 从一张 Excel 表到能跑通的进销存：数据库课设到底在考什么
很多同学拿到“某商店进销存管理系统”这个题目，第一反应是打开 IDE 写界面，结果两周后卡在“库存对不上”这种玄学 bug 上。我当年做类似课设时也翻过车：商品表里存了库存数量，采购单和销售单又各存一份，三处数据一改就打架。后来才想明白，这个题目的核心不是写一个好看的窗体，而是用数据库把“进—销—存”三条业务流串成一条闭环，让每一次采购入库、销售出库都能被追溯、被约束、被汇总。它适合正在学数据库原理、需要交一份能演示又能讲清楚设计思路的课程设计的同学，也适合想拿它当练手项目、把 SQL 和事务真正用起来的开发者。这一章先把业务边界和数据流讲透，后面再动手建表、写触发器、做报表。
进销存这三个字拆开看：进是采购，供应商把货送进来，库存增加；销是销售，顾客把货买走，库存减少；存是库存，任何时刻的结存数量都应该等于期初加上入库减去出库。听起来像废话，但真正落地时，90% 的错误都出在“存”这一环——要么是并发扣减导致超卖，要么是退货没回滚库存，要么是盘点调整没留痕。所以这个系统的设计目标可以概括成三句话：数据不重复、操作可追溯、库存能对账。数据库课设的评分点通常也在这三处：ER 图是否合理、范式是否到位、约束和事务是否用对。
我一般建议把整个系统拆成四个模块来想：基础资料（商品、供应商、客户、仓库）、采购管理（采购单、入库）、销售管理（销售单、出库）、库存管理（库存台账、盘点、预警）。每个模块对应一组表，表与表之间靠外键和业务主键关联。这样拆的好处是，后面写 SQL 和调 bug 时，你能快速定位问题出在哪条流上，而不是对着一张大宽表发呆。
2. 表结构怎么定：从 ER 图到能落地的建表语句
2.1 先画清楚实体和关系，再动手写 DDL
很多人跳过 ER 图直接建表，结果建到一半发现“一个采购单有多个商品”没地方放，只能回头改。正确的顺序是：先列出所有实体，再标出它们之间的基数关系，最后才翻译成表。这个系统里核心实体有：商品（Product）、供应商（Supplier）、客户（Customer）、仓库（Warehouse）、采购单（PurchaseOrder）、销售单（SalesOrder）、库存（Inventory）、库存流水（StockLog）。
关系上要注意几个关键点：一个采购单可以包含多个商品，所以采购单和商品之间是多对多，需要一张采购明细表来拆解；销售单同理。库存不是简单存在商品表里的一个字段，而应该是“商品 + 仓库”维度的记录，因为同一个商品可能放在不同仓库。库存流水则是每一次库存变动的原始凭证，采购入库、销售出库、盘点调整都要往这里写一条。
下面是我常用的建表语句，以 MySQL 8.0 为例，字段命名用下划线风格，主键统一用自增 bigint，金额用 decimal 避免浮点误差。
-- 商品表：只存基础属性，不存库存数量 CREATE TABLE product ( id BIGINT PRIMARY KEY AUTO_INCREMENT, product_code VARCHAR(32) NOT NULL UNIQUE COMMENT '商品编码，业务唯一', product_name VARCHAR(128) NOT NULL, category VARCHAR(64) DEFAULT NULL, unit VARCHAR(16) NOT NULL DEFAULT '件', purchase_price DECIMAL(12,2) NOT NULL DEFAULT 0.00, sale_price DECIMAL(12,2) NOT NULL DEFAULT 0.00, status TINYINT NOT NULL DEFAULT 1 COMMENT '1上架 0下架', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 库存表：商品+仓库维度，唯一约束防止重复行 CREATE TABLE inventory ( id BIGINT PRIMARY KEY AUTO_INCREMENT, product_id BIGINT NOT NULL, warehouse_id BIGINT NOT NULL, quantity INT NOT NULL DEFAULT 0 COMMENT '当前结存数量', updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_prod_wh (product_id, warehouse_id), CONSTRAINT fk_inv_product FOREIGN KEY (product_id) REFERENCES product(id), CONSTRAINT fk_inv_wh FOREIGN KEY (warehouse_id) REFERENCES warehouse(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;这里有两个设计决策值得说清楚。第一，库存数量没有放在 product 表里，而是单独一张 inventory 表，因为库存是“商品 × 仓库”的组合属性，放在商品表里会导致多仓库场景无法表达。第二，inventory 上加了uk_prod_wh唯一约束，这样后面用INSERT ... ON DUPLICATE KEY UPDATE做入库累加时不会产生重复行，这是很多课设里容易忽略的细节。
2.2 采购、销售、流水三张表的字段取舍
采购单和销售单的结构类似，都是“主表 + 明细表”的模式。主表存单号、供应商/客户、总金额、状态、操作人、时间；明细表存商品、数量、单价、金额。这里有个常见坑：明细表里的金额到底存不存？我的做法是存，因为单价可能随批次变化，实时用数量乘单价算虽然也行，但历史单据一旦单价被改就会失真。存下来相当于留了一份快照。
库存流水表是整个系统的“黑匣子”，任何库存变动都必须往这里写一条，字段包括：商品、仓库、变动类型（采购入库/销售出库/盘点调整/退货入库）、变动数量（正数入库、负数出库）、变动前数量、变动后数量、关联单号、操作时间。有了这张表，库存对不上时可以直接查流水，而不是靠猜。
-- 库存流水：每一次变动都留痕，便于对账和排查 CREATE TABLE stock_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, product_id BIGINT NOT NULL, warehouse_id BIGINT NOT NULL, change_type VARCHAR(16) NOT NULL COMMENT 'PURCHASE_IN/SALE_OUT/CHECK_ADJUST', change_qty INT NOT NULL COMMENT '正数入库，负数出库', before_qty INT NOT NULL, after_qty INT NOT NULL, ref_order_no VARCHAR(32) DEFAULT NULL COMMENT '关联单号', operator VARCHAR(32) DEFAULT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_prod_time (product_id, created_at), CONSTRAINT fk_log_product FOREIGN KEY (product_id) REFERENCES product(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;参数上要注意change_qty用有符号整数，入库为正、出库为负，这样统计某段时间的净变动只需要SUM(change_qty)，不用区分类型。before_qty和after_qty看起来冗余，但在排查“某次操作后库存跳变”时非常有用，能直接定位是哪一笔写错了。索引idx_prod_time是为后面按商品查流水准备的，课设数据量不大，但养成加索引的习惯没坏处。
3. 库存扣减与事务：把超卖和负库存挡在数据库层
3.1 为什么应用层判断库存不可靠
新手最容易写出的逻辑是：先SELECT quantity FROM inventory WHERE ...，在代码里判断quantity >= 购买数量，然后再UPDATE inventory SET quantity = quantity - N。这个写法在单用户演示时没问题，一旦有两个操作同时进来就会翻车：两个事务都读到库存 10，都判断通过，都扣 5，最后库存变成 0 但实际卖出了 10 件，这就是典型的超卖。
数据库课设里老师未必会压测，但答辩时如果被问到“并发怎么办”，答不上来会扣分。正确的做法是把判断和扣减合并到一条 SQL 里，利用数据库的行锁和条件更新来保证原子性。
-- 原子扣减：只有库存足够时才更新，返回受影响行数 UPDATE inventory SET quantity = quantity - #{buyQty} WHERE product_id = #{productId} AND warehouse_id = #{warehouseId} AND quantity >= #{buyQty};这条语句执行后，检查返回的受影响行数：如果是 1，说明扣减成功；如果是 0，说明库存不足或商品仓库不存在，直接抛业务异常回滚事务。这样就不存在“读—判断—写”之间的时间窗口，数据库在执行 UPDATE 时会对目标行加排他锁，其他事务必须等待。
3.2 一个完整的销售出库事务长什么样
销售出库不只是扣库存，还要写销售单、写明细、写流水，这几步必须在一个事务里，要么全成功要么全回滚。下面是一个用 JDBC 风格伪代码写的完整流程，重点看事务边界和异常处理。
// 伪代码：销售出库事务，所有操作在同一连接同一事务内 Connection conn = dataSource.getConnection(); try { conn.setAutoCommit(false); // 开启事务 // 1. 插入销售单主表，拿到自增主键 Long orderId = salesOrderDao.insert(conn, order); // 2. 逐条处理明细：扣库存 + 写流水 + 写明细 for (OrderItem item : order.getItems()) { int affected = inventoryDao.deduct(conn, item.getProductId(), item.getWarehouseId(), item.getQty()); if (affected == 0) { throw new BizException("库存不足：" + item.getProductCode()); } // 查询扣减后的库存，写入流水 int afterQty = inventoryDao.queryQty(conn, item.getProductId(), item.getWarehouseId()); stockLogDao.insert(conn, item, afterQty + item.getQty(), afterQty, order.getOrderNo()); salesItemDao.insert(conn, orderId, item); } conn.commit(); // 全部成功才提交 } catch (Exception e) { conn.rollback(); // 任何一步失败整体回滚 throw e; } finally { conn.setAutoCommit(true); conn.close(); }这里的关键点是：所有 DAO 方法都接收同一个conn，保证在同一个事务里；扣库存用条件更新，返回 0 就抛异常触发回滚；流水里的before_qty用afterQty + item.getQty()反推，避免再多查一次。事务隔离级别用默认的 REPEATABLE READ 就够了，因为扣减靠的是行锁而不是快照读。
注意：如果课设要求用 Spring 的
@Transactional，记得把扣库存和写流水放在同一个 Service 方法里，并且异常要抛出 RuntimeException 才会触发回滚，受检异常默认不回滚。
3.3 盘点调整和退货入库怎么处理
盘点调整是直接改库存数量，但同样要留流水。做法是：先查出当前库存beforeQty，算出差异diff = actualQty - beforeQty，然后UPDATE inventory SET quantity = actualQty，再往流水里写一条change_type='CHECK_ADJUST'、change_qty=diff的记录。退货入库则相当于一次采购入库，只是关联单号指向退货单，change_type可以用RETURN_IN。
这两种操作的共同点是：不要直接改 inventory 而不写流水。我见过有同学为了省事，盘点时直接UPDATE完就结束了，结果期末对账时发现流水加总和库存对不上，查了一晚上。血泪经验就是：库存表是“当前状态”，流水表是“变更历史”，两者必须同步维护，缺一不可。
4. 查询与报表：用 SQL 把进销存数据讲成故事
4.1 库存结存查询：别再用子查询硬算了
课设答辩时经常被要求“查出每个商品当前库存”。如果库存表设计得当，直接SELECT p.product_name, i.quantity FROM inventory i JOIN product p ON ...就出来了。但如果当初把库存放在流水里靠SUM算，每次查询都要扫全表，数据一多就慢。这也是我坚持单独建 inventory 表的原因之一。
不过有时候需要“截至某一天的库存”，这就得用流水来算了。比如查 2024-06-01 的结存，可以用：
-- 查询指定日期各商品的库存结存（基于流水汇总） SELECT p.product_code, p.product_name, COALESCE(SUM(sl.change_qty), 0) AS stock_qty FROM product p LEFT JOIN stock_log sl ON sl.product_id = p.id AND sl.created_at < '2024-06-01 00:00:00' GROUP BY p.id, p.product_code, p.product_name ORDER BY p.product_code;这里用LEFT JOIN是为了让没有流水的商品也显示出来，库存为 0。COALESCE把 NULL 转成 0，避免前端显示空。条件放在ON里而不是WHERE里，是因为WHERE会把没有流水的商品过滤掉，这是很多人写报表时容易犯的错。
4.2 销售排行与库存预警：两个高频报表的写法
销售排行通常按商品汇总销售数量和金额，时间范围可选。写法是销售明细表关联销售主表，按商品分组求和，再按金额倒序。
-- 近30天商品销售排行 SELECT p.product_code, p.product_name, SUM(si.quantity) AS total_qty, SUM(si.amount) AS total_amount FROM sales_item si JOIN sales_order so ON so.id = si.order_id JOIN product p ON p.id = si.product_id WHERE so.status = 'PAID' AND so.created_at >= DATE_SUB(NOW(), INTERVAL 30 DAY) GROUP BY p.id, p.product_code, p.product_name ORDER BY total_amount DESC LIMIT 20;库存预警则是查 inventory 里数量低于安全库存的商品。安全库存可以放在 product 表加一个safe_stock字段，也可以单独建配置表。课设里简单起见直接加字段就行。
-- 库存预警：低于安全库存的商品 SELECT p.product_code, p.product_name, i.quantity, p.safe_stock FROM inventory i JOIN product p ON p.id = i.product_id WHERE i.quantity < p.safe_stock ORDER BY (p.safe_stock - i.quantity) DESC;这两个报表的 SQL 都不复杂，但答辩时老师往往会追问“如果同一商品在不同仓库都有库存，预警怎么算”。这时候要么按仓库分别预警，要么先按商品汇总再比较。我一般建议按仓库维度预警，因为补货是按仓库补的，汇总了反而不好操作。
5. 避坑与排查：课设里最容易翻车的五个地方
5.1 库存对不上：先查流水，再查事务边界
现象是演示时发现某个商品库存数量和流水加总不一致。原因通常有两种：一是某次操作改了 inventory 但没写 stock_log，二是事务没包住，扣了库存但单据插入失败回滚了。排查方法是先跑一条对账 SQL：
-- 对账：库存表数量 vs 流水汇总数量 SELECT i.product_id, i.quantity AS inv_qty, COALESCE(SUM(sl.change_qty), 0) AS log_qty FROM inventory i LEFT JOIN stock_log sl ON sl.product_id = i.product_id AND sl.warehouse_id = i.warehouse_id GROUP BY i.product_id, i.warehouse_id, i.quantity HAVING i.quantity <> COALESCE(SUM(sl.change_qty), 0);查出来不一致的记录，再去看对应时间段的流水和单据，基本能定位到是哪一步漏了。解决方式就是补流水或者修正库存，同时检查代码里所有改库存的地方是否都写了流水、是否都在事务里。
5.2 外键约束导致删不掉数据
现象是想删除一个测试商品，报外键约束错误。原因是 inventory 或 stock_log 里有引用它的记录。这不是 bug，是外键在保护数据一致性。解决方式有两种：要么先删子表记录再删主表，要么把外键改成ON DELETE CASCADE。但课设里我不建议用级联删除，因为库存流水是审计数据，不应该跟着商品一起消失。正确做法是把商品status置为下架，而不是物理删除。
5.3 金额用 float 导致对账差几分钱
现象是销售单总金额和明细加总差 0.01。原因是用了 float 或 double 存金额，浮点运算有精度损失。解决方式是把所有金额字段改成DECIMAL(12,2)，Java 里用BigDecimal，不要用double。这个坑在课设里非常常见，改起来也简单，但如果不改，答辩演示时对账对不上会很尴尬。
5.4 并发扣减返回 0 但库存明明够
现象是压测或多人同时下单时，明明库存充足却提示库存不足。原因可能是扣减 SQL 的 WHERE 条件写错了，比如把warehouse_id写成了warehouse_code，或者参数传反了。排查时先把 SQL 拿到客户端手动执行，把参数替换成实际值，看受影响行数。另一个可能是事务隔离级别用了 SERIALIZABLE 导致锁等待超时，课设里用默认级别即可。
5.5 时间字段用字符串存导致范围查询失效
现象是查“近 30 天销售”时结果不对。原因是created_at用了 VARCHAR 存'2024/6/1'这种格式，字符串比较和日期比较结果不一致。解决方式是统一用DATETIME或TIMESTAMP，插入时用NOW()，查询时用DATE_SUB。如果历史数据已经是字符串，先用STR_TO_DATE转换再改字段类型。
6. 从能跑到能讲：把课设变成可复现的工程习惯
课设做到能演示只是及格线，真正拉开差距的是你能不能把设计决策讲清楚，以及这套东西能不能被别人复现。我一般会做三件事：第一，写一个schema.sql把所有建表语句、索引、外键、初始数据整理成一个文件，别人拿到就能一键建库；第二，写一个README说明每个模块的业务流程和关键 SQL，尤其是库存扣减和流水写入的逻辑；第三，准备一组测试数据，覆盖正常入库、正常出库、库存不足、盘点调整四种场景，演示时按顺序跑一遍，比口头解释有说服力。
进阶一点的做法是把库存流水做成“事件溯源”的简化版：inventory 表只是流水的一个物化视图，任何时候都可以通过重放流水重建。这样即使 inventory 被误改，也能从流水恢复。实现方式就是写一个重建脚本：
-- 从流水重建库存表（先清空再汇总插入） TRUNCATE TABLE inventory; INSERT INTO inventory (product_id, warehouse_id, quantity) SELECT product_id, warehouse_id, SUM(change_qty) FROM stock_log GROUP BY product_id, warehouse_id;这个脚本在课设答辩时是个很好的加分项，因为它证明你理解“状态”和“事件”的关系。但要注意，生产环境不能随便 TRUNCATE，这里只是演示重建思路。
最后说一个我自己的习惯：每次改完库存相关的代码，一定手动跑一遍“采购入库 10 件 → 销售出库 3 件 → 盘点调整为 5 件 → 查库存和流水是否一致”这个最小闭环。这个习惯帮我省了很多次答辩前熬夜查 bug 的时间。数据库课设看起来是在考 SQL，其实是在考你有没有把业务规则翻译成数据约束的能力。把这一点想通，后面做任何管理系统都会顺很多。希望帮到你。
本文还有配套的精品资源，点击获取
