简介这是一份面向数据库课程设计的商场管理系统完整工程包基于SQL Server 2008数据库实现适合需要完成课程作业或练习数据库编程的同学。系统覆盖商品类型与基本信息、供应商、员工等模块的维护并实现了进货管理、入库管理中的信息查询、修改、删除以及库存更新与进货/库存分析等功能。资源共8个文件压缩后约343KB主要包括3个sql脚本触发器、存储过程、查询视图、1份需求分析报告、1份数据字典、1个数据库关系图ER1以及数据库文件和日志文件mdf/ldf可帮助读者直接还原数据库环境。目前已有216人学习浏览。通过该资源可以获得完整的需求分析文档、数据字典、可执行的触发器与存储过程示例以及现成的数据库备份便于对照理解SQL Server编程在实际商贸管理场景中的具体应用。1. 课程设计不是“会建表”就行商场管理系统的三件套才是得分点一份商场管理系统的数据库课程设计答辩时老师常常不看界面先问三件事数据库备份文件摆在哪、存储过程写了几个、触发器挡住了哪些非法操作。只做到“能建表、能增删改查”的项目在这一关基本答不上来。这套课设题目的价值恰好落在数据库课程里最实用的三个能力上——备份、触发器、存储过程——再配一份需求报告把商品、库存、会员、销售单据串成一条能自圆其说的业务线。做完它你手里留下的不只是一个课设 zip 包而是一套可以直接搬去真实小系统的数据库骨架。本文按需求报告→表结构→存储过程→触发器→备份还原→验收自检的顺序把每一块怎么做、参数怎么调、哪里容易翻车讲清楚适合正在准备数据库课程设计、或者想补这三块实战的同学。2. 从需求报告到表结构把销售单主表和明细表先立住2.1 需求报告里必须写清的三类业务规则需求报告不是来凑页数的它是后面所有表结构、存储过程、触发器的设计依据。商场管理系统的需求报告里业务规则写得越具体后面动手就越省事。我一般会建议把规则分成三类去写任何一条都能在后面的数据库对象里找到对应实现。第一类是“开单规则”一个顾客买多个商品一张销售单带多个明细同时扣减对应商品库存库存不够时整单不做而不是只扣有货的部分。第二类是“会员规则”消费按金额累计积分积分可以在下次消费时抵现但抵现金额有上限。第三类是“商品规则”售价不等于进价调价要留记录改价不能直接改历史销售明细。这三类规则必须写具体是因为课程设计验收时老师看需求报告通常只看三分钟看的是有没有可验证的业务定义而不是抄来的系统功能列表。你写“支持商品管理、会员管理、销售管理”等于没写写上“库存不足时不允许生成销售单”这才是一条能在触发器里验收的需求。2.2 核心表结构与建表SQL商场管理系统我一般会建六张表商品表 Goods、库存表 Inventory、会员表 Member、销售主表 SaleOrder、销售明细表 SaleItem、库存流水表 StockLog。销售相关拆两张表的原因是同一张销售单会包含多种商品如果把商品都塞进主表一行字段宽度失控而且没法直接统计“某个商品卖了多少”。拆开后主表存订单级信息明细表存商品级信息通过外键关联。建表脚本以 SQL Server 为语法基准CREATE TABLE Goods ( GoodsId VARCHAR(20) PRIMARY KEY, -- 商品编码不用自增列做主键 GoodsName NVARCHAR(50) NOT NULL, SalePrice DECIMAL(10,2) NOT NULL, -- 金额用decimalfloat会出精度误差 CostPrice DECIMAL(10,2) NOT NULL, IsActive BIT DEFAULT 1 ); CREATE TABLE Inventory ( GoodsId VARCHAR(20) PRIMARY KEY, StockQty INT NOT NULL DEFAULT 0, LastUpdate DATETIME DEFAULT GETDATE(), CONSTRAINT FK_Inventory_Goods FOREIGN KEY (GoodsId) REFERENCES Goods(GoodsId) ); CREATE TABLE Member ( MemberId VARCHAR(20) PRIMARY KEY, MemberName NVARCHAR(50) NOT NULL, Phone VARCHAR(20) UNIQUE, Points INT NOT NULL DEFAULT 0 -- 积分冗余在会员表消费时累加 ); CREATE TABLE SaleOrder ( OrderNo VARCHAR(30) PRIMARY KEY, -- 业务单号日期流水号 MemberId VARCHAR(20) NULL, OperatorId VARCHAR(20) NOT NULL, OrderTime DATETIME DEFAULT GETDATE(), TotalAmount DECIMAL(10,2) NOT NULL, CONSTRAINT FK_SaleOrder_Member FOREIGN KEY (MemberId) REFERENCES Member(MemberId) ); CREATE TABLE SaleItem ( ItemId INT IDENTITY(1,1) PRIMARY KEY, OrderNo VARCHAR(30) NOT NULL, GoodsId VARCHAR(20) NOT NULL, Qty INT NOT NULL CHECK (Qty 0), -- 数量不能为负 RealPrice DECIMAL(10,2) NOT NULL, SubTotal DECIMAL(10,2) NOT NULL, CONSTRAINT FK_SaleItem_Order FOREIGN KEY (OrderNo) REFERENCES SaleOrder(OrderNo), CONSTRAINT FK_SaleItem_Goods FOREIGN KEY (GoodsId) REFERENCES Goods(GoodsId) ); CREATE TABLE StockLog ( LogId INT IDENTITY(1,1) PRIMARY KEY, GoodsId VARCHAR(20) NOT NULL, ChangeQty INT NOT NULL, -- 正数为入库负数为出库 ChangeTime DATETIME DEFAULT GETDATE(), Remark NVARCHAR(100) NULL );这段脚本用最少的表覆盖商场系统核心业务设计上故意做了两处冗余销售明细里的 RealPrice 冗余当前售价会员表的 Points 冗余积分总额。这两个冗余是为后面存储过程和触发器服务的不算设计缺陷。这里有几个选型细节值得单独说。库存为什么不直接放在 Goods 表里因为商品是静态资料库存是不断变化的量拆出 Inventory 表后做库存流水对账会方便很多。数量字段用 INT、金额字段用 DECIMAL这是课设里最常见的低级错误来源——有人用 float 存金额两张表加出来的小计差几分钱对不上账就是这个原因。商品主键用 VARCHAR 业务编码而不是自增 INT因为销售单据从条形码或 Excel 导入取商品时自增 ID 在跨库还原和手工录入场景下容易对不上号。销售明细表还需要给 OrderNo 和 GoodsId 各建一个非聚集索引。日结报表按 OrderNo 汇总销量统计按 GoodsId 分组缺索引时数据一多查询必然变慢。课设数据量小可能感觉不到但答辩时老师如果问“你这个报表为什么快”索引就是现成的答案。2.3 字段类型和约束的选型建表阶段另一个重点是定约束。销售明细的数量约束 CHECK (Qty 0) 是底线默认值 DEFAULT 0 用在积分和库存上UNIQUE 用在会员手机号上外键用在所有明细关联上。这些约束在答辩时可以直接回答“你怎么保证数据完整性”比口头说“我用了外键”更有说服力。再单独说一下冗余字段的取舍。现场调试最容易翻车的场景是存储过程里扣了库存打开界面发现库存没变——因为界面读的是 Goods 表而存储过程扣的是 Inventory 表。解决方案只有一条整个系统里“库存”只认 Inventory 一张表界面查询、报表汇总都从 Inventory 取数不要在别的表里再存一份库存数字。这条规则写进需求报告能帮你省掉一多半对不上账的麻烦。建表完成后的自检方法也很简单把需求报告里写的三条规则逐条翻译成 SQL 查询看能不能查出来。比如“某天卖得最多的商品是哪个”如果这条 SQL 要跨三张表 join说明表结构基本合理如果一条 SQL 都写不出来说明表拆错了趁早改。3. 存储过程把销售开单、日结对账封装成数据库事务3.1 为什么课设里必须出现存储过程不少同学的课设是界面代码里直接写 SQL把增删改查全交给客户端。这种做法能运行但它掩盖了一个问题一次销售操作需要同时完成“写订单、写明细、扣库存、加积分”四件事客户端写成四条 SQL任何一步断掉数据库就剩一半数据。存储过程的价值在于把多条 SQL 装进一个事务要么全成功要么全回滚。答辩时老师问“你的事务怎么实现的”答案就是“存储过程里用 BEGIN TRANSACTION / COMMIT / ROLLBACK”。这也是课设题目点名要“触发器存储过程”的原因它们是事务和业务规则在数据库层的载体。用 SQL Server 写和用 MySQL 写语法有差异但设计思路一致下面以 SQL Server 为主线。对比项客户端直写 SQL存储过程封装事务边界分散在应用层断网即脏数据数据库层统一提交回滚业务规则每个客户端各写一套集中在一处改规则只改一处答辩表现只能答“我用了事务”能讲清事务起点和回滚条件3.2 销售开单存储过程参数、事务与逐条明细先定义一个表值参数类型用来接收一张销售单里的多行明细。这是 SQL Server 把“多条明细传进存储过程”最干净的做法避免用字符串拼明细再解析。CREATE TYPE SaleItemTVP AS TABLE ( GoodsId VARCHAR(20), Qty INT );然后用这个表值参数写销售开单的存储过程CREATE PROCEDURE usp_Sale_CreateOrder OrderNo VARCHAR(30), MemberId VARCHAR(20), OperatorId VARCHAR(20), Items SaleItemTVP READONLY AS BEGIN SET NOCOUNT ON; DECLARE TotalAmount DECIMAL(10,2) 0; DECLARE GoodsId VARCHAR(20), Qty INT, Price DECIMAL(10,2); BEGIN TRY BEGIN TRANSACTION; -- 订单头、明细、扣库存、积分在同一事务里 -- 逐行读取传入的明细生成小计累加总额 DECLARE cur CURSOR FOR SELECT GoodsId, Qty FROM Items; OPEN cur; FETCH NEXT FROM cur INTO GoodsId, Qty; WHILE FETCH_STATUS 0 BEGIN SELECT Price SalePrice FROM Goods WHERE GoodsId GoodsId; SET TotalAmount TotalAmount Price * Qty; FETCH NEXT FROM cur INTO GoodsId, Qty; END CLOSE cur; DEALLOCATE cur; -- 写入订单头 INSERT INTO SaleOrder(OrderNo, MemberId, OperatorId, TotalAmount) VALUES (OrderNo, MemberId, OperatorId, TotalAmount); -- 写入明细并扣库存、记库存流水 DECLARE cur2 CURSOR FOR SELECT GoodsId, Qty FROM Items; OPEN cur2; FETCH NEXT FROM cur2 INTO GoodsId, Qty; WHILE FETCH_STATUS 0 BEGIN SELECT Price SalePrice FROM Goods WHERE GoodsId GoodsId; INSERT INTO SaleItem(OrderNo, GoodsId, Qty, RealPrice, SubTotal) VALUES (OrderNo, GoodsId, Qty, Price, Price * Qty); UPDATE Inventory SET StockQty StockQty - Qty WHERE GoodsId GoodsId; INSERT INTO StockLog(GoodsId, ChangeQty, Remark) VALUES (GoodsId, -Qty, NSale: OrderNo); FETCH NEXT FROM cur2 INTO GoodsId, Qty; END CLOSE cur2; DEALLOCATE cur2; -- 会员积分按整单金额累加 IF MemberId IS NOT NULL UPDATE Member SET Points Points CAST(TotalAmount AS INT) WHERE MemberId MemberId; COMMIT TRANSACTION; END TRY BEGIN CATCH IF TRANCOUNT 0 ROLLBACK TRANSACTION; THROW; -- 把原始错误抛给调用方界面层能看到真实原因 END CATCH END;这段代码用游标是为了读得直观实际生产里很多人会用集合写法但对课设来说游标更接近“看得懂每一行在干什么”。参数说明OrderNo 是业务单号建议调用方生成格式用日期加流水号例如 20250512-0001OperatorId 是收银员 IDItems 是表值参数对应界面上一次勾选的商品明细。事务的边界是这段代码的重点。订单头、明细插入、库存扣减、积分更新都在 BEGIN TRANSACTION 和 COMMIT TRANSACTION 之间任何一个环节 THROWCATCH 里 ROLLBACK 会把整单撤销。答辩时老师最常追问“如果第二条商品库存不足第一条会不会留下”答案就是不会整单回滚。应用层调用这个存储过程也很短DECLARE items SaleItemTVP; INSERT INTO items VALUES (G001, 2); INSERT INTO items VALUES (G002, 1); EXEC usp_Sale_CreateOrder 20250512-0001, M001, E001, items;如果库存不足这里会直接收到 THROW 抛出的 51000 错误信息界面层捕获后弹窗提示即可。调用失败时先看错误号51000 是业务拦截其余数字多为字段长度或外键冲突按提示排查。3.3 日结统计存储过程答辩时可以现场演示的报表第二个存储过程建议做成“日结报表”。它解决的不是写入而是查询技术上覆盖 GROUP BY 和聚合函数答辩时打开它跑一遍效果比菜单查询好得多。CREATE PROCEDURE usp_Sale_DailyReport BizDate DATE AS BEGIN SET NOCOUNT ON; SELECT CONVERT(DATE, OrderTime) AS BizDate, COUNT(DISTINCT OrderNo) AS OrderCount, SUM(TotalAmount) AS TotalAmount, SUM(CASE WHEN MemberId IS NOT NULL THEN 1 ELSE 0 END) AS MemberOrderCount FROM SaleOrder WHERE CONVERT(DATE, OrderTime) BizDate GROUP BY CONVERT(DATE, OrderTime); END;这个存储过程只有一个参数 BizDate调用时传 2025-05-12 就能拿到当天订单数、销售总额、会员订单占比。演示时先插入几条测试数据再执行 EXEC usp_Sale_DailyReport 2025-05-12一张对账报表就出来了。存储过程的数量不是越多越好。课设有个常见误动作是为了凑含量建十几个“SELECT * FROM X”的存储过程老师一看就是在灌水。正常配置是两个核心业务存储过程加两个查询报表每个都有明确的参数和事务设计比二十个空壳有说服力。如果老师追问权限问题还能补一句存储过程默认只给执行权限普通账号无法直接改表数据只能调过程这也是选它的理由之一。4. 触发器库存扣减校验与会员积分的自动化4.1 触发器在商场系统里的三个落点存储过程保证了从正规入口写入时业务规则成立但数据库里还有第三方工具、临时 SQL、数据导入这些不走正规入口的通道。触发器的价值是把业务规则在数据库这一层强制生效不管数据从哪进来。商场系统里最常见的触发器落点有三个库存不足拦截销售明细、会员积分自动累计、关键表变更写日志。选择触发器位置的原则是业务上有“不经过应用层也必须保证”的强制约束就放触发器只要应用层做一次就够的约束不建议放。课设题目既然点名要求触发器说明前一类约束必须真实存在否则触发器就是硬凑的。顺便说一个常见误用有人试图用 CHECK 约束完成库存校验写成 CHECK (StockQty 0)。这个约束只能约束库存表自身拦不住“卖出了比库存更多的货”这个跨表逻辑因为 SaleItem 插入时 Inventory 表并不感知。跨表业务规则必须用触发器或存储过程这正是课设要求触发器存在的原因。4.2 用 INSTEAD OF 触发器拦截库存不足的销售明细库存扣减可以在存储过程里做也可以放在触发器里。更稳妥的组合是存储过程负责正常业务再用一个 INSTEAD OF 触发器在明细插入时做最后一道库存校验防止任何绕过存储过程的 INSERT 把库存打成负数。这里用 INSTEAD OF 而不是 AFTER 的原因要讲清楚。AFTER 触发器在 INSERT 执行之后才触发插入动作本身已经完成要拦截只能靠抛错误回滚事务流程上是“先写坏数据再擦掉”。INSTEAD OF 触发器是替 SQL Server 执行一段自定义逻辑校验不通过就直接收手不真正写数据逻辑更干净。CREATE TRIGGER trg_SaleItem_CheckStock ON SaleItem INSTEAD OF INSERT AS BEGIN SET NOCOUNT ON; DECLARE GoodsId VARCHAR(20), Qty INT; DECLARE cur CURSOR FOR SELECT GoodsId, Qty FROM inserted; OPEN cur; FETCH NEXT FROM cur INTO GoodsId, Qty; WHILE FETCH_STATUS 0 BEGIN IF NOT EXISTS (SELECT 1 FROM Inventory WHERE GoodsId GoodsId AND StockQty Qty) BEGIN CLOSE cur; DEALLOCATE cur; THROW 51000, N库存不足已拒绝该笔明细, 1; -- 报告给调用方触发事务回滚 END FETCH NEXT FROM cur INTO GoodsId, Qty; END CLOSE cur; DEALLOCATE cur; -- 校验通过后由触发器代为完成真正插入 INSERT INTO SaleItem(OrderNo, GoodsId, Qty, RealPrice, SubTotal) SELECT OrderNo, GoodsId, Qty, SalePrice, SalePrice * Qty FROM inserted i JOIN Goods g ON g.GoodsId i.GoodsId; END;这段触发器的关键点是魔法表 inserted。DML 触发器被触发后SQL Server 会把本次操作写入的新行放进 inserted 表触发器读取它就能拿到“这次试图插入什么数据”。校验通过后原本要执行的 INSERT 由触发器手动补上数据才真正落库。库存不足时 THROW 抛出的错误会传递到调用方如果这个 INSERT 发生在存储过程事务内部事务会随 THROW 一起回滚。提示INSTEAD OF 触发器里手动补 INSERT 时字段必须和原操作语义对齐。漏掉 RealPrice 或 SubTotal报表立刻对不上账。4.3 用 AFTER 触发器做会员积分和操作日志积分累计适合用 AFTER 触发器。销售明细写入成功之后积分按照本单实际金额增加这属于“主操作成功后的连带操作”放在 AFTER 触发器里语义正好。CREATE TRIGGER trg_SaleItem_AddPoints ON SaleItem AFTER INSERT AS BEGIN SET NOCOUNT ON; UPDATE m SET Points Points CAST(o.TotalAmount AS INT) FROM Member m JOIN SaleOrder o ON m.MemberId o.MemberId WHERE o.OrderNo IN (SELECT DISTINCT OrderNo FROM inserted) AND m.MemberId IS NOT NULL; END;这里有一个很容易被忽略的坑如果 Member 表上还有别的 UPDATE 触发器这个 UPDATE 会再次触发形成触发器链。本案例中 Member 表不带 UPDATE 触发器所以安全如果 Member 表必须有 UPDATE 触发器就得用 sys.triggers 排查触发链必要时通过嵌套触发器开关控制。课设答辩很少问到这层但真实系统里经常出这种事。操作日志是第三种典型触发器。在 Goods 表上挂 AFTER UPDATE把改动前后的值写进日志表核心是读取 inserted 和 deleted 两张魔法表做对比。这个触发器强烈建议做因为演示时“改个价格再查日志表”是全场最直观的场景比口头解释触发器原理有效得多。触发器的验证方法要写进你的自检清单-- 验证手工插入一条超过库存的明细应当收到51000错误 INSERT INTO SaleItem(OrderNo, GoodsId, Qty, RealPrice, SubTotal) VALUES (20250512-0001, G001, 99999, 10, 999990);在查询分析器里执行这条 INSERT观察是否收到“库存不足”错误。收到说明触发器生效了。验证完把这条测试数据清掉否则会污染日结报表。批量导入初始化数据时如果被触发器拖慢可以用 ALTER TABLE ... DISABLE TRIGGER 临时关掉导入完再启用这个操作答辩时主动说出来反而是加分项。5. 数据库备份与还原排查四个容易翻车的细节5.1 备份命令怎么选完整备份差异备份先讲基本操作。SQL Server 的备份命令本身不长关键在于选对备份类型和还原参数。-- 完整备份把整个数据库做成一个.bak文件 BACKUP DATABASE MallDB TO DISK ND:\Backup\MallDB_Full.bak WITH INIT, NAME NMallDB-Full Backup; -- 差异备份记录自上次完整备份以来的变化文件小还原快 BACKUP DATABASE MallDB TO DISK ND:\Backup\MallDB_Diff.bak WITH DIFFERENTIAL, INIT;课设交付时交一个完整备份文件就够但答辩演示建议做成“完整备份差异备份”两步先完整备份再插入几条数据做差异备份还原时按顺序还原两次展示“差异备份只补了新增数据”。备份文件还有版本兼容问题要提前确认高版本实例备份出来的 .bak 文件低版本实例还原不了。比如 SQL Server 2012 的备份文件拿到 2008 实例上还原直接报版本不支持。答辩前先确认演示机器的数据库版本别到现场才发现备份文件打不开。5.2 还原时数据库被占用独占访问权被拒绝现象执行 RESTORE 时提示数据库正在使用无法获得独占访问权。原因本地开发工具、浏览器连接或刚才打开的查询窗口还占着这个库。还原操作需要独占锁所有连接都必须先断掉包括你自己那个停在查询窗口的会话。解决先切到 master 库把目标库踢成单用户模式还原完成后再改回多用户。这套操作对课设演示足够用。USE master; ALTER DATABASE MallDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE; RESTORE DATABASE MallDB FROM DISK ND:\Backup\MallDB_Full.bak WITH REPLACE; ALTER DATABASE MallDB SET MULTI_USER;这里 WITH ROLLBACK IMMEDIATE 会把卡住的连接直接断开WITH REPLACE 允许覆盖现有同名数据库。这两个参数是课设还原最常用的两个开关记不住别的也要记住这两个。5.3 备份文件写不进去操作系统错误5现象BACKUP DATABASE 报错 operating system error 5(Access is denied)备份文件根本没生成。原因SQL Server 服务账号对目标目录没有写权限。这个坑在把备份目录改到自定义路径时最容易出现D 盘新建的 Backup 文件夹默认没有给 SQL Server 服务账号授权。解决两个办法二选一。一是把备份路径改回 SQL Server 默认的备份目录二是给备份文件夹授予 SQL Server 服务账号写入权限。实操中改路径比调权限快课设环境直接给 D 盘 Backup 文件夹授权也行。5.4 WITH RECOVERY 和 WITH NORECOVERY 的区别现象完整备份还原成功后紧接着还原差异备份报错提示当前数据库处于已恢复状态无法继续还原备份链。原因完整备份还原时默认带 WITH RECOVERY这一步完成后数据库已经处于可用状态日志链已经闭合后续差异备份自然接不上。解决还原完整备份时用 WITH NORECOVERY让库保持“正在还原”状态再还原差异备份最后一步用 WITH RECOVERY 打开数据库。顺序不能乱。USE master; RESTORE DATABASE MallDB FROM DISK ND:\Backup\MallDB_Full.bak WITH NORECOVERY, REPLACE; RESTORE DATABASE MallDB FROM DISK ND:\Backup\MallDB_Diff.bak WITH RECOVERY;这个知识点是备份环节最值钱的一个。答辩时老师问“完整备份和差异备份有什么区别、顺序怎么排”答案就在这两行里完整备份打底差异备份增量最后一次恢复必须带 RECOVERY 收尾。5.5 还原后账号对不上登录名映射丢失现象把备份文件拷到另一台电脑还原成功但原来的账号登录不进去只有 sa 或其他管理员能进。原因备份文件里包含的是数据库用户不含服务器级登录名。用户和登录名的对应关系SID 映射存在目标服务器的 master 库中换机器后这条映射丢失。解决在目标服务器为数据库用户重建登录名并绑定。课设答辩时最省事的做法是还原后立刻用 ALTER USER 重新指定一个可用的登录名或者演示时就只让管理员登录。真实系统的正规做法是用 sp_change_users_login 修复课设阶段知道原理即可。6. 把备份收尾定时差异备份与还原自检技巧备份做完只算完成一半另一半是验证它能还原。我的习惯是课设答辩前一天一定做一次完整的“还原演练”把备份文件还原到一个新库 MallDB_Test跑一遍日结存储过程行数对得上才放心。这个动作不花时间但能救回现场演示时“备份文件打不开”的尴尬。如果需要把备份变成自动任务SQL Server Express 版没有 SQL Server Agent最简单的做法是让 Windows 任务计划程序定时跑一个 bat 脚本脚本内容就是一行 sqlcmd。以每天晚上凌晨 1 点做差异备份为例sqlcmd -S .\SQLEXPRESS -E -Q BACKUP DATABASE MallDB TO DISKD:\Backup\MallDB_Diff.bak WITH DIFFERENTIAL, INIT在 Windows 任务计划程序里建一个“每天 01:00 运行”的触发器即可。对课设而言这一步是加分项说明你想到了“备份是可重复执行的运维动作”而不是答辩现场手敲一次。最后说一个我自己的血泪教训当年课设交上去的备份文件是从实验室机器导出的演示那台电脑还原后存储过程能跑但登录名全丢现场只能用管理员身份硬着头皮演示。后来我每次做完数据库改动第一件事就是还原本机新库自检一遍确认存储过程和触发器都在、日结报表能查出数来。这套“改完就还原自检”的习惯比课设分数本身更值钱。希望帮到你。本文还有配套的精品资源点击获取
