简介面向计算机专业课程设计与数据库入门实践的「小型自选商场商品管理系统」完整项目包围绕商品进货、销售、库存、供应商与收银台等业务环节展开适合需要完成数据库课程设计或桌面管理系统的学习者参考。压缩包共189个文件约680KB以60个SQL脚本、54个C#源码文件及24个resx资源文件为主体另含项目解决方案、配置文件、数据库文件和可执行程序覆盖建表、业务逻辑、界面布局与运行环境。已有1027人学习下载。读者可从中获取进货与售货记录、按月统计、日盘存与月盘存、动态库存刷新、供应商查询及收银清单打印等功能的实现思路并通过库存、售货、进货、供应商四类表的设计理解关系型数据库建模方法适合对照课程要求进行拆解与二次开发。1. 收银台前的排队不致命月底盘亏才要命某社区自选商场有三个收银台、四千多个SKU之前用表格记库存每天打烊手动扣减账实不符是常态——货架上还有货系统显示零系统显示有货货架早空了。月底一盘亏两三万老板说不清是丢货还是记错账。他要的不是大而全的ERP而是一套能把商品档案、库存变动和销售流水串起来的数据库商品管理系统。这套方案解决的核心问题只有一个让每一笔出入库都留痕、可追溯、能对账。适合拿它做数据库课设或毕设的学生也适合给周边小店做轻量数字化的小团队。界面做得再花哨数据库设计立不住后面全是返工。这篇按需求、选型、表结构、模块实现、避坑、验收的顺序拆开讲能照着搭一套跑得通的系统。2. 需求拆解与技术选型五个角色、三条数据流和一个单库架构动手建表之前先把“谁在用、数据怎么流、量有多大”这三件事定下来。小型自选商场的业务链条其实很短采购把货进来库管上架收银员卖出去店长看数和补货老板月底对账。链条短不代表简单角色交叉和数据重复录入最容易把系统做成四不像。2.1 角色与场景五种人的操作边界自选商场的岗位分工不细一个人可能同时管收货和上架但系统里的权限必须按最小职责切开否则收银员能改进货价账就永远对不平。我一般会拆成五个角色角色核心操作数据权限收银员扫码结算、退货只读商品价格写销售单库管入库、出库、盘点读写库存看商品基础信息采购新建采购单、维护供应商读写采购与供应商表店长商品维护、调价、看报表全部业务表老板查报表、审单据只读全部权限落到数据库层就是账号与角色表落到代码层就是接口拦截。学生做课设常犯的错是把权限写成前端按钮隐藏后端接口裸奔答辩时老师用一个改过的请求就能绕过这点要提前防。三条核心数据流要画清楚销售流收银→销售单→扣库存→记流水、采购流采购单→入库→加库存→记流水、盘点流实盘数→差异→调库存→记盘点记录。所有库存变动最终都汇聚到一张库存流水表这张表是整个系统的账本后面第3章细讲。2.2 技术选型单库MySQL为什么比分布式更合适四千个SKU、日均几百单、峰值并发不超过二十个收银终端的场景上分布式数据库或分库分表纯属给自己找麻烦。单机MySQL 8.0配合InnoDB完全扛得住事务、行锁、外键约束都是现成的。后端我习惯用Spring Boot加MyBatis原因是课设和毕设环境下资料多、调试方便遇到问题容易定位如果团队更熟PythonFlask加SQLAlchemy同样可行核心是SQL和事务逻辑框架只是外壳。前端用Vue或纯模板渲染都行商品管理系统的前端复杂度不高重点是表单校验和列表分页。缓存先不上二十个并发用Redis是过度设计反而多一个要维护的组件。真到了几百并发再考虑加缓存层这是后话。提示选型的判断标准不是“先进”而是“出了问题你能不能在两小时内定位”。毕设环境里一个你完全没碰过的中间件往往是答辩翻车的起点。2.3 总体架构三层结构与多模块职责划分整体按经典三层走别嫌老套小系统用分层能省掉大量扯皮表现层收银台界面、后台管理页、报表页负责输入校验和结果展示不做业务判断。业务层商品服务、库存服务、销售服务、采购服务、报表服务。库存扣减、价格计算、权限校验全部在这一层完成。数据层MySQL加MyBatis映射所有SQL集中管理事务边界开在Service方法上。模块之间的调用关系要单向销售服务调库存服务扣减库存服务调商品服务校验状态反向依赖一律禁止。我见过有同学在商品服务里直接写销售逻辑最后改一个字段要在三个文件里翻血泪经验。模块划分清晰了后面每个模块的代码才有可能被单独演示、单独测试答辩时也能一块一块讲。2.4 数据量估算与非功能指标给数据库定几个硬指标后面设计和验收都有依据商品表初始四千条年增长不超过两千条库存流水表日均约一千条一年三十六万条三年百万级单表完全可控销售单日均三百到五百单明细按每单平均五条算一年约九十万条明细商品列表查询响应控制在300毫秒内收银结算单笔控制在500毫秒内数据保留三年超期流水归档到历史表主表只留近期数据保证查询速度。这些数字不是拍脑袋是从“三个收银台、每天营业十二小时”反推的。指标定下来第3章建索引和第6章验收才有尺子可量。3. 数据库设计从商品主数据到库存流水的八张核心表数据库设计是这个系统真正的骨架。界面可以改框架可以换表结构一旦上线再动就是伤筋动骨。这一章把实体关系、核心DDL、索引策略和库存事务四件事讲透照着能直接建库。3.1 实体关系梳理八张表撑起整个业务核心实体有八个商品、分类、供应商、库存、库存流水、销售单、销售明细、采购单。关系上分类对商品是一对多供应商对商品是一对多一个商品默认一个主供应商商品对库存是一对一商品对库存流水是一对多销售单对销售明细是一对多销售明细对商品是多对一。有两处设计容易被做错。第一库存数量不要直接挂在商品表上单独建库存表原因是商品基础信息和库存变动频率差好几个数量级混在一起每次扣库存都要锁商品行查询商品列表时又被库存字段拖慢。第二销售明细里要冗余商品名称和成交单价不能只存商品ID。商品改名或调价后历史订单必须显示当时的名字和价格这是对账的底线会计上叫“历史快照”。这个冗余不是设计缺陷是刻意为之。3.2 核心表DDL与字段说明先看商品表和库存表这两张是主数据-- 商品表存基础档案不含库存数量 CREATE TABLE product ( id BIGINT PRIMARY KEY AUTO_INCREMENT, barcode VARCHAR(32) NOT NULL COMMENT 条码收银扫码用, name VARCHAR(100) NOT NULL COMMENT 商品名称, category_id BIGINT NOT NULL COMMENT 分类ID, supplier_id BIGINT DEFAULT NULL COMMENT 主供应商ID, purchase_price DECIMAL(10,2) NOT NULL DEFAULT 0 COMMENT 进货价, sale_price DECIMAL(10,2) NOT NULL DEFAULT 0 COMMENT 零售价, unit VARCHAR(16) NOT NULL DEFAULT 件 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_category (category_id), KEY idx_name (name) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商品主表; -- 库存表一个商品一行记录当前数量与预警线 CREATE TABLE stock ( id BIGINT PRIMARY KEY AUTO_INCREMENT, product_id BIGINT NOT NULL COMMENT 商品ID, quantity INT NOT NULL DEFAULT 0 COMMENT 当前库存, warn_threshold INT NOT NULL DEFAULT 10 COMMENT 库存预警线, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_product (product_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT库存表;几个字段值得单独说。barcode加唯一索引收银扫码时按条码查商品走的是唯一索引速度有保证同时防止同一条码重复录入。purchase_price和sale_price都用DECIMAL(10,2)而不是FLOAT金额计算用浮点数会出现0.1加0.2不等于0.3的玄学问题对账时能查出几分钱的差异却找不到原因这种坑没必要踩。status用0和1控制停售商品下架不删记录历史订单还要关联它。库存流水的DDL是重点它是整个系统的黑匣子-- 库存流水表每次库存变动都必须写一条 CREATE TABLE stock_flow ( id BIGINT PRIMARY KEY AUTO_INCREMENT, product_id BIGINT NOT NULL COMMENT 商品ID, change_type TINYINT NOT NULL COMMENT 1入库 2销售出库 3退货入库 4盘盈亏 5报损, change_qty INT NOT NULL COMMENT 变动数量正数增加负数减少, before_qty INT NOT NULL COMMENT 变动前库存, after_qty INT NOT NULL COMMENT 变动后库存, ref_type VARCHAR(20) DEFAULT NULL COMMENT 关联单据类型, ref_id BIGINT DEFAULT NULL COMMENT 关联单据ID, operator VARCHAR(50) NOT NULL COMMENT 操作人, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_product_time (product_id, created_at), KEY idx_ref (ref_type, ref_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT库存流水表;before_qty和after_qty两个字段是我强烈建议加的。很多课设只记变动数量出问题时没法还原当时的状态加这两个字段后任何一笔变动都能倒推出整条链相当于给库存上了后悔药。ref_type和ref_id指向来源单据销售出库指向销售单入库指向采购单对账时按单据一查就知道这笔库存变动的来龙去脉。3.3 索引策略与典型查询写法索引不是越多越好商品管理系统的查询集中在三个方向按条码查单品、按名称或分类模糊查列表、按时间查流水。对应的索引在上面的DDL里已经埋好这里说两个常被忽略的点。商品名称的模糊查询如果写成LIKE %洗发水%idx_name索引用不上全表扫四千行其实也不慢但数据量涨到几万行就会显形。我的做法是列表页默认按分类过滤加条码或名称前缀匹配前缀匹配LIKE 洗发水%能走索引真要全文模糊搜索再单独上全文索引或搜索引擎小系统先用前缀匹配兜住别一上来就上Elasticsearch。库存预警查询是高频操作写法上注意别用函数包字段-- 正确能走索引直接比较两列 SELECT p.id, p.name, s.quantity, s.warn_threshold FROM stock s JOIN product p ON p.id s.product_id WHERE s.quantity s.warn_threshold AND p.status 1; -- 错误示范quantity - warn_threshold 0列上做运算索引失效预警查询在店长首页每次刷新都要跑数据量不大但频率高写法规范一点能省下不少CPU。3.4 库存扣减的事务设计与并发控制库存扣减是整个系统最容易出错的地方。收银员扫码结算背后要完成三件事写销售单、写销售明细、扣库存并记流水。这三步必须在一个事务里任何一步失败全部回滚否则会出现“卖了货没扣库存”或“扣了库存没单据”的账实不符。并发场景下还要防超卖。两个收银台同时卖最后一件商品如果先查库存再更新两边都查到有货都扣成负数。正确做法是用带条件的更新语句把判断和扣减合成一步-- 扣减库存WHERE 里带数量判断影响行数为0说明库存不足 UPDATE stock SET quantity quantity - #{qty} WHERE product_id #{productId} AND quantity #{qty}; -- 紧接着写流水before_qty 用查询结果after_qty 由 before_qty 减 qty 得出 INSERT INTO stock_flow(product_id, change_type, change_qty, before_qty, after_qty, ref_type, ref_id, operator) VALUES(#{productId}, 2, -#{qty}, #{beforeQty}, #{beforeQty} - #{qty}, SALE, #{saleId}, #{operator});UPDATE的影响行数要判断返回0就直接抛异常回滚事务提示“库存不足”。这个写法依赖InnoDB的行锁同一商品的并发扣减会排队执行不会超卖。事务注解开在Service方法上传播行为用默认的REQUIRED隔离级别用READ_COMMITTED就够别乱调成串行化性能会掉得很难看。4. 模块实现商品录入、库存预警、收银结算与报表的代码落地表结构定好接下来把五个业务模块逐个落地。这一章每个模块给关键代码和设计说明重点讲清楚“为什么这么写”而不是把增删改查铺一遍。能照着跑通的最小实现比十个花架子功能有用。4.1 商品信息管理与分类维护商品录入的难点不在表单在重复条码和分类树。条码唯一性由数据库唯一索引兜底插入时捕获DuplicateKeyException转成友好提示比先查再插可靠因为查和插之间有空窗期并发下照样能插重。分类维护如果做两级大类、小类表里加个parent_id自关联即可不必上无限级树商场场景两级足够。商品列表分页用LIMIT加COUNT每页二十条。注意COUNT查询在数据量大时也慢可以缓存总数或改成“下一页”游标式分页小系统先用LIMIT别过早优化。商品停售用状态位而不是物理删除原因是历史订单和流水都要关联商品删了外键就断对账时查不出东西。4.2 库存管理与预警机制库存模块对外暴露三个核心方法入库、出库、盘点调整。三个方法内部都走同一套“改库存加记流水”的模板区别只在change_type和ref_type。抽一个公共方法出来避免三处代码各写各的后面改逻辑只改一处。预警机制不用定时任务直接在库存表上挂预警线店长首页查询quantity warn_threshold的商品即可。如果非要自动推送用Spring的Scheduled每小时扫一次把预警商品写进消息表前端轮询展示别上消息队列这个体量用不上。盘点是特殊场景实盘数和账面数不一致时差异要写进流水change_type记为4变动数量是实盘减账面。盘点单要保留原始实盘数方便复核很多同学直接把库存改成实盘数却不留记录月底老板问“这批货怎么少的”就答不上来。4.3 销售收银与采购入库流程收银结算的代码结构要清晰接收购物车明细校验商品状态和库存生成销售单号在一个事务里写单、写明细、扣库存、记流水。销售单号用“日期加流水号”生成比如S20240615001方便按天对账。退货走反向流程change_type记3库存加回去销售单标记退货状态而不是删除账目必须留痕。采购入库相对简单采购单审核通过后调库存入库方法change_type记1ref_type记PURCHASE。要注意的是入库价格更新如果这次进货价和商品表里的purchase_price不一致是否更新商品主表我的做法是更新同时把旧价记进价格变更日志方便追溯成本波动。这个日志表不是必须的但对做毕设的同学是个加分项答辩时能讲出成本核算的思路。4.4 数据统计与报表导出报表模块至少做三张日销售汇总、商品销售排行、库存预警清单。日销售汇总按日期分组统计销售额和单数SQL里用DATE(created_at)分组注意这个写法用不上索引数据量大时改成范围查询加应用层聚合。商品销售排行按销量降序取前二十关联商品表带出名称。库存预警清单就是3.3节那条查询。导出用POI或EasyExcel写Excel别在数据库层拼字符串。报表数据量小同步导出即可不用上异步任务。店长月底对账要的就是这几张表做扎实比做多更重要。5. 常见问题与排查库存对不上、查询变慢、事务失效的避坑手册系统跑起来只是开始真正折磨人的是运行中冒出来的怪问题。这一章列五个项目里最容易翻车的点每条按“现象、原因、解决”写都是能直接对照排查的。5.1 库存流水和账面数量对不上现象库存表显示某商品还有五十件把流水表按商品汇总一算只有四十八件差两件。原因九成是某次库存变动只改了库存表没写流水或者写了流水没改库存两步没在同一个事务里。常见于盘点调整和退货入库这两个分支开发时图省事直接UPDATE stock了事。解决把“改库存加记流水”封成一个不可拆分的服务方法事务注解开在这个方法上禁止任何地方直接操作库存表。排查时写一条对账SQL按商品汇总流水变动和库存当前值比对差额不为零的商品就是问题点再按created_at倒序查该商品的流水找断档的时间点。-- 对账SQL流水汇总与库存当前值比对 SELECT s.product_id, s.quantity AS stock_qty, COALESCE(SUM(f.change_qty), 0) AS flow_qty, s.quantity - COALESCE(SUM(f.change_qty), 0) AS diff FROM stock s LEFT JOIN stock_flow f ON f.product_id s.product_id GROUP BY s.product_id, s.quantity HAVING diff 0;5.2 商品列表越用越慢现象刚上线时列表秒开用了两个月翻到后面几页要等两三秒。原因分页查询用了LIMIT 10000, 20这种大偏移量MySQL要扫过前一万行再丢弃越翻越慢或者列表查询关联了流水表做统计笛卡尔积把结果撑爆。解决列表页禁止关联流水表需要统计数字就单独查或加冗余字段。大偏移量改成游标分页前端记住上一页最后一条的ID下一页用WHERE id lastId LIMIT 20。另外检查EXPLAIN执行计划确认走了索引没走索引就补索引或改写SQL别靠加机器硬扛。5.3 事务回滚失效卖了货库存没退现象测试时故意让销售明细插入失败结果销售单回滚了库存却扣掉了数据彻底乱套。原因库存扣减方法被同类内部直接调用Spring的AOP代理没生效Transactional形同虚设或者异常被try-catch吞掉没重新抛出事务管理器收不到回滚信号。解决事务方法必须通过代理调用同类内部调用要么抽到另一个Service要么用AopContext.currentProxy()前者更干净。catch块里如果处理了异常末尾一定要throw出去或者手动调TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()。这两个坑我都踩过排查时看日志里事务有没有真正开启比盯着代码猜快得多。5.4 中文乱码和备份恢复翻车现象商品名里的生僻字变成问号或者从备份恢复后部分数据乱码。原因建库时字符集用了utf8而不是utf8mb4生僻字和表情符号存不下连接串没指定字符集备份用mysqldump没带--default-character-setutf8mb4。解决建库建表统一utf8mb4加utf8mb4_general_ci排序规则连接串加characterEncodingutf8备份脚本固定字符集参数。恢复前先在测试库跑一遍确认数据完整再动生产库。备份这件事没恢复验证过的备份等于没有备份。6. 验收与答辩用一组数据和一张核对表证明系统真跑通了到了验收环节最怕的是系统能点开但讲不清。答辩老师不会逐个按钮点他们看三样东西数据对不对、流程通不通、边界有没有考虑。提前准备一套完整的演示数据和一份核对清单比现场手忙脚乱强太多。6.1 验收清单六项必须现场跑通验收项操作通过标准商品建档新增一个带条码的商品重复条码被拦截提示明确采购入库采购单审核入库库存增加流水有一条入库记录收银结算卖两件商品库存减二流水有销售记录金额正确库存不足卖超过库存的数量事务回滚提示库存不足库存不变退货对已售商品退货库存加回销售单标记退货流水有退货记录对账跑5.1节对账SQL所有商品差额为零这六项跑完系统的核心闭环就验证了。演示数据提前准备好建十个商品、两个分类、一个供应商造三笔采购和五笔销售数据量小但覆盖所有变动类型现场操作快结果也好看。6.2 答辩演示脚本与追问应对演示按“建档、入库、销售、退货、对账”的顺序走五分钟内讲完。每一步说完操作立刻切到数据库客户端展示对应的表和流水记录让老师看到界面背后的数据变化这比口头讲架构有说服力。老师最常追问三个点库存并发怎么防超卖、事务边界划在哪、历史订单为什么能显示旧价格。前两个用3.4节的条件更新和事务注解回答第三个用销售明细的字段冗余回答。如果被问到“数据量涨十倍怎么办”老实说单表百万级加索引够用分库分表是更大规模才考虑的事别不懂装懂。还有一个容易被忽略的细节演示前把数据库备份一份现场操作万一改错数据五分钟内能恢复到演示初始状态。我一般会在答辩前把演示脚本在干净环境里完整走两遍第一遍找流程漏洞第二遍掐时间。从那以后我每次交付系统都强制自己按验收清单跑一遍不管多赶这一遍省不掉。希望这套结构和清单能帮到你照着搭少走我走过的弯路。本文还有配套的精品资源点击获取
简介面向计算机专业课程设计与数据库入门实践的「小型自选商场商品管理系统」完整项目包围绕商品进货、销售、库存、供应商与收银台等业务环节展开适合需要完成数据库课程设计或桌面管理系统的学习者参考。压缩包共189个文件约680KB以60个SQL脚本、54个C#源码文件及24个resx资源文件为主体另含项目解决方案、配置文件、数据库文件和可执行程序覆盖建表、业务逻辑、界面布局与运行环境。已有1027人学习下载。读者可从中获取进货与售货记录、按月统计、日盘存与月盘存、动态库存刷新、供应商查询及收银清单打印等功能的实现思路并通过库存、售货、进货、供应商四类表的设计理解关系型数据库建模方法适合对照课程要求进行拆解与二次开发。1. 收银台前的排队不致命月底盘亏才要命某社区自选商场有三个收银台、四千多个SKU之前用表格记库存每天打烊手动扣减账实不符是常态——货架上还有货系统显示零系统显示有货货架早空了。月底一盘亏两三万老板说不清是丢货还是记错账。他要的不是大而全的ERP而是一套能把商品档案、库存变动和销售流水串起来的数据库商品管理系统。这套方案解决的核心问题只有一个让每一笔出入库都留痕、可追溯、能对账。适合拿它做数据库课设或毕设的学生也适合给周边小店做轻量数字化的小团队。界面做得再花哨数据库设计立不住后面全是返工。这篇按需求、选型、表结构、模块实现、避坑、验收的顺序拆开讲能照着搭一套跑得通的系统。2. 需求拆解与技术选型五个角色、三条数据流和一个单库架构动手建表之前先把“谁在用、数据怎么流、量有多大”这三件事定下来。小型自选商场的业务链条其实很短采购把货进来库管上架收银员卖出去店长看数和补货老板月底对账。链条短不代表简单角色交叉和数据重复录入最容易把系统做成四不像。2.1 角色与场景五种人的操作边界自选商场的岗位分工不细一个人可能同时管收货和上架但系统里的权限必须按最小职责切开否则收银员能改进货价账就永远对不平。我一般会拆成五个角色角色核心操作数据权限收银员扫码结算、退货只读商品价格写销售单库管入库、出库、盘点读写库存看商品基础信息采购新建采购单、维护供应商读写采购与供应商表店长商品维护、调价、看报表全部业务表老板查报表、审单据只读全部权限落到数据库层就是账号与角色表落到代码层就是接口拦截。学生做课设常犯的错是把权限写成前端按钮隐藏后端接口裸奔答辩时老师用一个改过的请求就能绕过这点要提前防。三条核心数据流要画清楚销售流收银→销售单→扣库存→记流水、采购流采购单→入库→加库存→记流水、盘点流实盘数→差异→调库存→记盘点记录。所有库存变动最终都汇聚到一张库存流水表这张表是整个系统的账本后面第3章细讲。2.2 技术选型单库MySQL为什么比分布式更合适四千个SKU、日均几百单、峰值并发不超过二十个收银终端的场景上分布式数据库或分库分表纯属给自己找麻烦。单机MySQL 8.0配合InnoDB完全扛得住事务、行锁、外键约束都是现成的。后端我习惯用Spring Boot加MyBatis原因是课设和毕设环境下资料多、调试方便遇到问题容易定位如果团队更熟PythonFlask加SQLAlchemy同样可行核心是SQL和事务逻辑框架只是外壳。前端用Vue或纯模板渲染都行商品管理系统的前端复杂度不高重点是表单校验和列表分页。缓存先不上二十个并发用Redis是过度设计反而多一个要维护的组件。真到了几百并发再考虑加缓存层这是后话。提示选型的判断标准不是“先进”而是“出了问题你能不能在两小时内定位”。毕设环境里一个你完全没碰过的中间件往往是答辩翻车的起点。2.3 总体架构三层结构与多模块职责划分整体按经典三层走别嫌老套小系统用分层能省掉大量扯皮表现层收银台界面、后台管理页、报表页负责输入校验和结果展示不做业务判断。业务层商品服务、库存服务、销售服务、采购服务、报表服务。库存扣减、价格计算、权限校验全部在这一层完成。数据层MySQL加MyBatis映射所有SQL集中管理事务边界开在Service方法上。模块之间的调用关系要单向销售服务调库存服务扣减库存服务调商品服务校验状态反向依赖一律禁止。我见过有同学在商品服务里直接写销售逻辑最后改一个字段要在三个文件里翻血泪经验。模块划分清晰了后面每个模块的代码才有可能被单独演示、单独测试答辩时也能一块一块讲。2.4 数据量估算与非功能指标给数据库定几个硬指标后面设计和验收都有依据商品表初始四千条年增长不超过两千条库存流水表日均约一千条一年三十六万条三年百万级单表完全可控销售单日均三百到五百单明细按每单平均五条算一年约九十万条明细商品列表查询响应控制在300毫秒内收银结算单笔控制在500毫秒内数据保留三年超期流水归档到历史表主表只留近期数据保证查询速度。这些数字不是拍脑袋是从“三个收银台、每天营业十二小时”反推的。指标定下来第3章建索引和第6章验收才有尺子可量。3. 数据库设计从商品主数据到库存流水的八张核心表数据库设计是这个系统真正的骨架。界面可以改框架可以换表结构一旦上线再动就是伤筋动骨。这一章把实体关系、核心DDL、索引策略和库存事务四件事讲透照着能直接建库。3.1 实体关系梳理八张表撑起整个业务核心实体有八个商品、分类、供应商、库存、库存流水、销售单、销售明细、采购单。关系上分类对商品是一对多供应商对商品是一对多一个商品默认一个主供应商商品对库存是一对一商品对库存流水是一对多销售单对销售明细是一对多销售明细对商品是多对一。有两处设计容易被做错。第一库存数量不要直接挂在商品表上单独建库存表原因是商品基础信息和库存变动频率差好几个数量级混在一起每次扣库存都要锁商品行查询商品列表时又被库存字段拖慢。第二销售明细里要冗余商品名称和成交单价不能只存商品ID。商品改名或调价后历史订单必须显示当时的名字和价格这是对账的底线会计上叫“历史快照”。这个冗余不是设计缺陷是刻意为之。3.2 核心表DDL与字段说明先看商品表和库存表这两张是主数据-- 商品表存基础档案不含库存数量 CREATE TABLE product ( id BIGINT PRIMARY KEY AUTO_INCREMENT, barcode VARCHAR(32) NOT NULL COMMENT 条码收银扫码用, name VARCHAR(100) NOT NULL COMMENT 商品名称, category_id BIGINT NOT NULL COMMENT 分类ID, supplier_id BIGINT DEFAULT NULL COMMENT 主供应商ID, purchase_price DECIMAL(10,2) NOT NULL DEFAULT 0 COMMENT 进货价, sale_price DECIMAL(10,2) NOT NULL DEFAULT 0 COMMENT 零售价, unit VARCHAR(16) NOT NULL DEFAULT 件 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_category (category_id), KEY idx_name (name) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商品主表; -- 库存表一个商品一行记录当前数量与预警线 CREATE TABLE stock ( id BIGINT PRIMARY KEY AUTO_INCREMENT, product_id BIGINT NOT NULL COMMENT 商品ID, quantity INT NOT NULL DEFAULT 0 COMMENT 当前库存, warn_threshold INT NOT NULL DEFAULT 10 COMMENT 库存预警线, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_product (product_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT库存表;几个字段值得单独说。barcode加唯一索引收银扫码时按条码查商品走的是唯一索引速度有保证同时防止同一条码重复录入。purchase_price和sale_price都用DECIMAL(10,2)而不是FLOAT金额计算用浮点数会出现0.1加0.2不等于0.3的玄学问题对账时能查出几分钱的差异却找不到原因这种坑没必要踩。status用0和1控制停售商品下架不删记录历史订单还要关联它。库存流水的DDL是重点它是整个系统的黑匣子-- 库存流水表每次库存变动都必须写一条 CREATE TABLE stock_flow ( id BIGINT PRIMARY KEY AUTO_INCREMENT, product_id BIGINT NOT NULL COMMENT 商品ID, change_type TINYINT NOT NULL COMMENT 1入库 2销售出库 3退货入库 4盘盈亏 5报损, change_qty INT NOT NULL COMMENT 变动数量正数增加负数减少, before_qty INT NOT NULL COMMENT 变动前库存, after_qty INT NOT NULL COMMENT 变动后库存, ref_type VARCHAR(20) DEFAULT NULL COMMENT 关联单据类型, ref_id BIGINT DEFAULT NULL COMMENT 关联单据ID, operator VARCHAR(50) NOT NULL COMMENT 操作人, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_product_time (product_id, created_at), KEY idx_ref (ref_type, ref_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT库存流水表;before_qty和after_qty两个字段是我强烈建议加的。很多课设只记变动数量出问题时没法还原当时的状态加这两个字段后任何一笔变动都能倒推出整条链相当于给库存上了后悔药。ref_type和ref_id指向来源单据销售出库指向销售单入库指向采购单对账时按单据一查就知道这笔库存变动的来龙去脉。3.3 索引策略与典型查询写法索引不是越多越好商品管理系统的查询集中在三个方向按条码查单品、按名称或分类模糊查列表、按时间查流水。对应的索引在上面的DDL里已经埋好这里说两个常被忽略的点。商品名称的模糊查询如果写成LIKE %洗发水%idx_name索引用不上全表扫四千行其实也不慢但数据量涨到几万行就会显形。我的做法是列表页默认按分类过滤加条码或名称前缀匹配前缀匹配LIKE 洗发水%能走索引真要全文模糊搜索再单独上全文索引或搜索引擎小系统先用前缀匹配兜住别一上来就上Elasticsearch。库存预警查询是高频操作写法上注意别用函数包字段-- 正确能走索引直接比较两列 SELECT p.id, p.name, s.quantity, s.warn_threshold FROM stock s JOIN product p ON p.id s.product_id WHERE s.quantity s.warn_threshold AND p.status 1; -- 错误示范quantity - warn_threshold 0列上做运算索引失效预警查询在店长首页每次刷新都要跑数据量不大但频率高写法规范一点能省下不少CPU。3.4 库存扣减的事务设计与并发控制库存扣减是整个系统最容易出错的地方。收银员扫码结算背后要完成三件事写销售单、写销售明细、扣库存并记流水。这三步必须在一个事务里任何一步失败全部回滚否则会出现“卖了货没扣库存”或“扣了库存没单据”的账实不符。并发场景下还要防超卖。两个收银台同时卖最后一件商品如果先查库存再更新两边都查到有货都扣成负数。正确做法是用带条件的更新语句把判断和扣减合成一步-- 扣减库存WHERE 里带数量判断影响行数为0说明库存不足 UPDATE stock SET quantity quantity - #{qty} WHERE product_id #{productId} AND quantity #{qty}; -- 紧接着写流水before_qty 用查询结果after_qty 由 before_qty 减 qty 得出 INSERT INTO stock_flow(product_id, change_type, change_qty, before_qty, after_qty, ref_type, ref_id, operator) VALUES(#{productId}, 2, -#{qty}, #{beforeQty}, #{beforeQty} - #{qty}, SALE, #{saleId}, #{operator});UPDATE的影响行数要判断返回0就直接抛异常回滚事务提示“库存不足”。这个写法依赖InnoDB的行锁同一商品的并发扣减会排队执行不会超卖。事务注解开在Service方法上传播行为用默认的REQUIRED隔离级别用READ_COMMITTED就够别乱调成串行化性能会掉得很难看。4. 模块实现商品录入、库存预警、收银结算与报表的代码落地表结构定好接下来把五个业务模块逐个落地。这一章每个模块给关键代码和设计说明重点讲清楚“为什么这么写”而不是把增删改查铺一遍。能照着跑通的最小实现比十个花架子功能有用。4.1 商品信息管理与分类维护商品录入的难点不在表单在重复条码和分类树。条码唯一性由数据库唯一索引兜底插入时捕获DuplicateKeyException转成友好提示比先查再插可靠因为查和插之间有空窗期并发下照样能插重。分类维护如果做两级大类、小类表里加个parent_id自关联即可不必上无限级树商场场景两级足够。商品列表分页用LIMIT加COUNT每页二十条。注意COUNT查询在数据量大时也慢可以缓存总数或改成“下一页”游标式分页小系统先用LIMIT别过早优化。商品停售用状态位而不是物理删除原因是历史订单和流水都要关联商品删了外键就断对账时查不出东西。4.2 库存管理与预警机制库存模块对外暴露三个核心方法入库、出库、盘点调整。三个方法内部都走同一套“改库存加记流水”的模板区别只在change_type和ref_type。抽一个公共方法出来避免三处代码各写各的后面改逻辑只改一处。预警机制不用定时任务直接在库存表上挂预警线店长首页查询quantity warn_threshold的商品即可。如果非要自动推送用Spring的Scheduled每小时扫一次把预警商品写进消息表前端轮询展示别上消息队列这个体量用不上。盘点是特殊场景实盘数和账面数不一致时差异要写进流水change_type记为4变动数量是实盘减账面。盘点单要保留原始实盘数方便复核很多同学直接把库存改成实盘数却不留记录月底老板问“这批货怎么少的”就答不上来。4.3 销售收银与采购入库流程收银结算的代码结构要清晰接收购物车明细校验商品状态和库存生成销售单号在一个事务里写单、写明细、扣库存、记流水。销售单号用“日期加流水号”生成比如S20240615001方便按天对账。退货走反向流程change_type记3库存加回去销售单标记退货状态而不是删除账目必须留痕。采购入库相对简单采购单审核通过后调库存入库方法change_type记1ref_type记PURCHASE。要注意的是入库价格更新如果这次进货价和商品表里的purchase_price不一致是否更新商品主表我的做法是更新同时把旧价记进价格变更日志方便追溯成本波动。这个日志表不是必须的但对做毕设的同学是个加分项答辩时能讲出成本核算的思路。4.4 数据统计与报表导出报表模块至少做三张日销售汇总、商品销售排行、库存预警清单。日销售汇总按日期分组统计销售额和单数SQL里用DATE(created_at)分组注意这个写法用不上索引数据量大时改成范围查询加应用层聚合。商品销售排行按销量降序取前二十关联商品表带出名称。库存预警清单就是3.3节那条查询。导出用POI或EasyExcel写Excel别在数据库层拼字符串。报表数据量小同步导出即可不用上异步任务。店长月底对账要的就是这几张表做扎实比做多更重要。5. 常见问题与排查库存对不上、查询变慢、事务失效的避坑手册系统跑起来只是开始真正折磨人的是运行中冒出来的怪问题。这一章列五个项目里最容易翻车的点每条按“现象、原因、解决”写都是能直接对照排查的。5.1 库存流水和账面数量对不上现象库存表显示某商品还有五十件把流水表按商品汇总一算只有四十八件差两件。原因九成是某次库存变动只改了库存表没写流水或者写了流水没改库存两步没在同一个事务里。常见于盘点调整和退货入库这两个分支开发时图省事直接UPDATE stock了事。解决把“改库存加记流水”封成一个不可拆分的服务方法事务注解开在这个方法上禁止任何地方直接操作库存表。排查时写一条对账SQL按商品汇总流水变动和库存当前值比对差额不为零的商品就是问题点再按created_at倒序查该商品的流水找断档的时间点。-- 对账SQL流水汇总与库存当前值比对 SELECT s.product_id, s.quantity AS stock_qty, COALESCE(SUM(f.change_qty), 0) AS flow_qty, s.quantity - COALESCE(SUM(f.change_qty), 0) AS diff FROM stock s LEFT JOIN stock_flow f ON f.product_id s.product_id GROUP BY s.product_id, s.quantity HAVING diff 0;5.2 商品列表越用越慢现象刚上线时列表秒开用了两个月翻到后面几页要等两三秒。原因分页查询用了LIMIT 10000, 20这种大偏移量MySQL要扫过前一万行再丢弃越翻越慢或者列表查询关联了流水表做统计笛卡尔积把结果撑爆。解决列表页禁止关联流水表需要统计数字就单独查或加冗余字段。大偏移量改成游标分页前端记住上一页最后一条的ID下一页用WHERE id lastId LIMIT 20。另外检查EXPLAIN执行计划确认走了索引没走索引就补索引或改写SQL别靠加机器硬扛。5.3 事务回滚失效卖了货库存没退现象测试时故意让销售明细插入失败结果销售单回滚了库存却扣掉了数据彻底乱套。原因库存扣减方法被同类内部直接调用Spring的AOP代理没生效Transactional形同虚设或者异常被try-catch吞掉没重新抛出事务管理器收不到回滚信号。解决事务方法必须通过代理调用同类内部调用要么抽到另一个Service要么用AopContext.currentProxy()前者更干净。catch块里如果处理了异常末尾一定要throw出去或者手动调TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()。这两个坑我都踩过排查时看日志里事务有没有真正开启比盯着代码猜快得多。5.4 中文乱码和备份恢复翻车现象商品名里的生僻字变成问号或者从备份恢复后部分数据乱码。原因建库时字符集用了utf8而不是utf8mb4生僻字和表情符号存不下连接串没指定字符集备份用mysqldump没带--default-character-setutf8mb4。解决建库建表统一utf8mb4加utf8mb4_general_ci排序规则连接串加characterEncodingutf8备份脚本固定字符集参数。恢复前先在测试库跑一遍确认数据完整再动生产库。备份这件事没恢复验证过的备份等于没有备份。6. 验收与答辩用一组数据和一张核对表证明系统真跑通了到了验收环节最怕的是系统能点开但讲不清。答辩老师不会逐个按钮点他们看三样东西数据对不对、流程通不通、边界有没有考虑。提前准备一套完整的演示数据和一份核对清单比现场手忙脚乱强太多。6.1 验收清单六项必须现场跑通验收项操作通过标准商品建档新增一个带条码的商品重复条码被拦截提示明确采购入库采购单审核入库库存增加流水有一条入库记录收银结算卖两件商品库存减二流水有销售记录金额正确库存不足卖超过库存的数量事务回滚提示库存不足库存不变退货对已售商品退货库存加回销售单标记退货流水有退货记录对账跑5.1节对账SQL所有商品差额为零这六项跑完系统的核心闭环就验证了。演示数据提前准备好建十个商品、两个分类、一个供应商造三笔采购和五笔销售数据量小但覆盖所有变动类型现场操作快结果也好看。6.2 答辩演示脚本与追问应对演示按“建档、入库、销售、退货、对账”的顺序走五分钟内讲完。每一步说完操作立刻切到数据库客户端展示对应的表和流水记录让老师看到界面背后的数据变化这比口头讲架构有说服力。老师最常追问三个点库存并发怎么防超卖、事务边界划在哪、历史订单为什么能显示旧价格。前两个用3.4节的条件更新和事务注解回答第三个用销售明细的字段冗余回答。如果被问到“数据量涨十倍怎么办”老实说单表百万级加索引够用分库分表是更大规模才考虑的事别不懂装懂。还有一个容易被忽略的细节演示前把数据库备份一份现场操作万一改错数据五分钟内能恢复到演示初始状态。我一般会在答辩前把演示脚本在干净环境里完整走两遍第一遍找流程漏洞第二遍掐时间。从那以后我每次交付系统都强制自己按验收清单跑一遍不管多赶这一遍省不掉。希望这套结构和清单能帮到你照着搭少走我走过的弯路。本文还有配套的精品资源点击获取
