简介数据库课程设计(花店管理系统)是一份完整的数据库课程设计报告面向计算机相关专业学生适用于数据库原理与实践类课程的结业设计参考。报告以花店管理系统为案例详细展示系统规划、用户需求分析、功能结构设计、数据库概念模型与逻辑模型、规范化分析以及SQL Server 2005/2008环境下的物理实现等完整流程帮助读者理解从需求调研到ER建模、表结构设计再到实际部署的每一步。压缩包内含1个PDF文档大小仅566KB内容紧凑但结构完整共1925人学习。文档包含系统目标、人员分工、业务流程分析、数据表设计、关键模块功能截图、缺陷改进及总结体会等板块特别适合需要参考课程设计报告写法、学习小型管理系统数据库建模或梳理数据库设计全过程的读者。通过该案例可以直观掌握数据库规范化原则、实体关系设计以及项目文档组织方法为独立完成同类设计提供有效范本。1. 花店管理系统课程设计一份PDF读懂数据库全流程做数据库课程设计时很多人卡在“从哪下手”题目只有一句话却要求系统规划、需求分析、ER图、建表脚本和模块实现全交一遍。我拆过不少课设资源要么只有截图没有设计过程要么把SQL堆在一起却没有说明为什么这么设计。这份《数据库课程设计花店管理系统.pdf》是少有的完整报告从线上线下结合的业务目标到管理员权限划分再到花、顾客、仓库、供应商四个实体的建模和增删改查实现最后连缺陷与改进都写了。它解决的不是你某个表怎么写而是“数据库课设的完整推演过程”。适合正在做课设的学生、要带新人写数据库的工程师以及想快速补一遍规范化设计流程的开发者。把这份PDF下载下来对着建库脚本敲一遍比自己从零写省事得多。2. 需求分析与概念模型把花店业务翻译成实体关系2.1 业务流程与角色权限这份报告开篇的系统规划写得很清楚开发目标是把实体店和网店结合形成线上线下同步发展的模式。这意味着需求分析不能只盯着“花店进销存”还得考虑顾客线上下单、门店零售、仓库补货之间的信息怎么串起来。报告里列的业务需求有两层一是界面简洁、便于操作二是多人同时操作并且有权限分配。这两句话看着简单实际上决定了后面数据库的权限模型和表的粒度。第一步先把角色拆开。管理员要能注册员工、查询修改花和客户的信息、对采购和出售进行调度店员只需要日常查询和订单录入。按照报告的功能分析还需要覆盖花信息管理、顾客管理、销售管理、花店供应管理和仓库管理。把这些功能画成一张角色权限表需求就清楚了一半。角色可读模块可写模块管理员花信息、顾客、订单、供应商、仓库员工注册、花/顾客信息修改、采购/销售调度店员花信息、顾客、订单销售订单录入、零售记录录入这张表的用途是建用户的时候每个数据库用户对应一个角色再通过GRANT控制权限。很多课设只做一个登录框登录之后所有人都是管理员这在报告里其实是被否掉的因为原文明确写了“要求有权限分配功能”。所以我在复现时会把权限设计放进数据库层程序里只传当前用户名。第二步把业务流程走一遍。最常见的流程是门店采购鲜花入库→仓库登记库存→顾客下单→销售出库→更新仓库数量。线上订单还要多一个配送信息但报告没有展开我就按线下为主、线上同步的思路做。流程走完你自然会发现哪些数据是必须存的哪些查询是高频的后面做物理设计时有依据。第三步把报告里的“功能分析”拆成操作动作花信息的新增、修改、删除、查询顾客资料的录入与查询销售订单的录入、修改、查询供应商信息记录仓库存储位置与数量管理。每个动作对应一个或多个SQL操作。我一般会把动作列成一张Checklist放在需求分析文档里写代码时不至于漏模块。这里有个常见的误区一上来就建表而不是先走业务。结果做到订单模块发现字段不够又回去改表外键全乱。报告里的开发计划其实写得很务实先完成主要目标再尝试补充功能最后测试改良、外观加工。这个顺序放到数据库设计里就是先做需求分析再做概念模型不要先写CREATE TABLE。2.2 实体清单与E-R图设计概念模型阶段的任务是找出实体和关系。报告直接给出了四个实体花、顾客、仓库、供应商并在实体关系图里标注了相互联系。按我的习惯会把“订购信息”也单独抽成实体因为订单是一个业务行为不能只写成花和顾客之间的一条连线否则订单编号、日期、数量这些属性没有地方挂。把实体和属性先列出来实体关键属性主键候选花花编号、名称、进货单价、销售单价花编号顾客顾客编号、姓名、性别、电话顾客编号供应商供应商编号、名称、联系人、电话供应商编号仓库仓库编号、花编号、花名、数量、位置仓库编号订单订单编号、花编号、顾客编号、数量、日期订单编号注意原始报告里“订购信息管理”写的是{花编号顾客姓名数量日期}这里把“顾客姓名”改为“顾客编号”。原因很简单顾客姓名会重复改名后历史订单无法追溯。如果回头去改顾客表订单里的姓名字段并不会跟着变。这是典型的更新异常第三范式就是干这个用的。报告里说规范化水平要高要求“表中记录应该有一个唯一的标识符”落实到订单表就是订单编号做主键顾客编号做外键。关系怎么定花和供应商是多对多一种花可以有多个供应商一个供应商可以供多种花中间需要一张供应关系表。顾客和订单是一对多一个顾客可以下多单。订单和花是多对多一张订单可能包含多种花需要订单明细表。花和仓库是一对多一个仓库可以存多种花一种花也可以分布在多个仓库更严谨的做法是单独建一张仓库花表。这些关系画在E-R图上就是报告里那张“实体间的关系图”的细化版。画E-R图的具体步骤我给一下第一步把需求分析中的所有名词过一遍能独立存在的抽成实体不能独立存在的抽成属性第二步给每个实体定主键第三步在两个实体之间找动词比如“订购”“存储”“供应”动词就是关系名第四步标注基数一个顾客对应多张订单一张订单对应多种花。这样画出来的图转关系模型时不会漏外键。2.3 从需求到数据字典先定字段再动手概念模型定完实体下一步不是直接建表而是先做数据字典。数据字典是逻辑模型的前身一行一个字段包含字段名、类型、长度、约束、说明。这一步能提前暴露很多设计问题比如“电话”字段到底要不要允许空订货日期用什么类型金额精度保留几位。我习惯先收集业务单据。花店每天会产生的单据包括进货单、零售单、线上订单、库存盘点表。每张单据上的栏位基本就是一张表的字段来源。进货单有供应商、花名、数量、进货单价、进货日期零售单有顾客、花名、数量、销售单价、日期库存表有花编号、花名、仓库位置、数量。然后按实体归类给每个字段选类型。常用规则是名称用NVARCHAR(50)电话用NVARCHAR(20)金额用DECIMAL(10,2)日期用DATETIME数量用INT。主键优先INT IDENTITY不要用业务编号。外键必须和主键同类型否则JOIN时隐式转换会让索引失效。数据字典做完逻辑模型基本就定了。报告中的“数据库逻辑模型”部分列了四张表但少了供应商表这是原报告的疏漏后面我会把表结构补全。总之需求分析到概念模型这段价值不是画图本身而是逼你把每个字段的来源和用途说清楚。很多项目做一半才发现字段对不上基本都是这一阶段偷懒。3. 逻辑与物理设计用 SQL Server 2008 建出可运行的花店库3.1 按范式拆表五张核心表的字段设计报告里的规范化分析写了五条要求避免可空列、不重复值或列、唯一标识符、统一前缀名、尽量只存储单一实体类型。这几句话是很多课设报告都会抄的但真正能把它落到建表语句里的人不多。以花店为例逐条对应看看。“避免可空列”不是让所有列都NOT NULL而是能用默认值解决的就不留空。比如花的库存数量默认0比允许NULL更好顾客电话可以允许空但姓名不能空。“不重复值或列”对应的是订单表里的花名、名称这类字段理论上应该引用花表而不是在订单表再存一份名称。“唯一标识符”就是每个表必须有主键。前缀名建议统一表名用模块前缀比如Flower_、Customer_避免系统里有几十张表互相认不清。如果按这三条标准检查原始报告会发现“订购信息管理{花编号顾客姓名数量日期}”这张表有问题它把顾客姓名直接存进来没有顾客编号外键也没有自己的订单编号。这样设计在作业演示阶段能跑但一旦要查“某个顾客买过哪些花”就得靠姓名去匹配姓名一改或者重名就全乱。我按报告功能推出来的核心表至少有六张Flower、Customer、Supplier、Warehouse、OrderInfo、OrderDetail。字段设计如下表表字段约束FlowerFlowerID, FlowerName, PurchasePrice, SalePrice, StockQtyFlowerID主键CustomerCustomerID, CustomerName, Gender, PhoneCustomerID主键SupplierSupplierID, SupplierName, Contact, PhoneSupplierID主键WarehouseWarehouseID, FlowerID, Qty, LocationWarehouseID主键FlowerID外键OrderInfoOrderID, CustomerID, OrderDateOrderID主键CustomerID外键OrderDetailDetailID, OrderID, FlowerID, Qty, PriceDetailID主键OrderIDFlowerID外键这样拆完每个实体一张窄表订单数据单独存放范式是合理的。第二范式要求非主键字段完全依赖主键OrderDetail里的Price依赖FlowerID但不依赖DetailID严格来说应该从Flower表带出来而不是冗余存储但是销售价格要考虑历史价所以我会在OrderDetail里冗余一列SalePrice并写明这是“有意冗余”。这就是课设报告里常说的“不能为了范式连业务都不要”。3.2 建库建表脚本参数、约束与默认值先建数据库-- 数据文件初始10MB最大100MB每次增长10MB -- 日志文件初始5MB最大50MB每次增长5MB CREATE DATABASE FlowerShop ON PRIMARY ( NAME NFlowerShop_Data, FILENAME ND:\Data\FlowerShop.mdf, SIZE 10MB, MAXSIZE 100MB, FILEGROWTH 10MB ) LOG ON ( NAME NFlowerShop_Log, FILENAME ND:\Data\FlowerShop_log.ldf, SIZE 5MB, MAXSIZE 50MB, FILEGROWTH 5MB );这段脚本在SQL Server 2005/2008上都能跑。SIZE是指初始大小FILEGROWTH是每次自动增长的量MAXSIZE封顶防止数据文件无限膨胀。FILENAME里的D:\Data目录要提前建好否则执行报错。如果你机器上只有默认路径可以直接把FILENAME去掉让SQL Server放到默认数据目录。然后建花表。花信息管理是系统最核心的主数据字段来自报告的逻辑模型-- 花表编号自增价格非负库存默认0 CREATE TABLE dbo.Flower ( FlowerID INT IDENTITY(1,1) NOT NULL, FlowerName NVARCHAR(50) NOT NULL, PurchasePrice DECIMAL(10,2) NOT NULL, SalePrice DECIMAL(10,2) NOT NULL, StockQty INT NOT NULL DEFAULT 0, CONSTRAINT PK_Flower PRIMARY KEY (FlowerID) );IDENTITY(1,1)表示从1开始每次加1数据库自己维护编号不会重复。NVARCHAR(50)支持中文和Unicode在SQL Server里比VARCHAR更稳。DECIMAL(10,2)表示整数10位小数2位金额够用。CHECK约束可以加在价格上-- 销售单价不能为负 ALTER TABLE dbo.Flower ADD CONSTRAINT CK_Flower_SalePrice CHECK (SalePrice 0);防止有人把销售单价写成负数。这些都是报告“数据库结构设计”部分缺失的细节课设答辩时被问“你有哪些约束”就从这里答。顾客表和订单表要体现实体关系-- 顾客表姓名必填电话允许空 CREATE TABLE dbo.Customer ( CustomerID INT IDENTITY(1,1) NOT NULL, CustomerName NVARCHAR(50) NOT NULL, Gender CHAR(2) NOT NULL DEFAULT N未填写, Phone NVARCHAR(20) NULL, CONSTRAINT PK_Customer PRIMARY KEY (CustomerID) ); -- 订单主表外键指向顾客默认下单时间 CREATE TABLE dbo.OrderInfo ( OrderID INT IDENTITY(1,1) NOT NULL, CustomerID INT NOT NULL, OrderDate DATETIME NOT NULL DEFAULT GETDATE(), CONSTRAINT PK_Order PRIMARY KEY (OrderID), CONSTRAINT FK_Order_Customer FOREIGN KEY (CustomerID) REFERENCES dbo.Customer(CustomerID) );代码要点外键不是必选项但有了它系统不会出现“订单挂在不存在顾客上”这种脏数据。OrderDate用GETDATE()做默认值录入时不用手动传时间。注意FK的外键列类型必须和主键列完全一致CustomerID都是INT否则建外键直接报错这是很多人踩过的坑。3.3 物理设计数据类型、索引与文件增长设置逻辑设计回答“有哪些表”物理设计回答“怎么存快”。报告里这句话说得对合理物理设计既要占用较少空间又要操作速度快。SQL Server 2008里最常用的物理优化手段就是索引。哪些列应该建索引主键自动有聚集索引外键列建议建非聚集索引因为订单表JOIN顾客表时SQL Server要通过外键列找匹配行没索引就要全表扫。查询频繁的列也可以建索引比如FlowerName。但不要每列都建索引会拖慢写入速度。-- 外键列加索引订单按顾客查询时避免全表扫描 CREATE NONCLUSTERED INDEX IX_Order_CustomerID ON dbo.OrderInfo(CustomerID);文件增长参数在上一节已经提过这里再补充一个细节如果FILEGROWTH设置太小比如1MB数据库会频繁自动增长产生文件碎片设置太大又会浪费磁盘空间。10MB的初始值和10%的增长比例是课设项目里比较稳的选择。数据类型的选择也属于物理设计。名称全部用NVARCHAR因为中文环境下VARCHAR可能出现半个字符的问题单价用DECIMAL而不用FLOAT因为浮点金额会有0.10.2不等于0.3这类问题数量用INT够用。性别字段用CHAR(2)值域固定不用NVARCHAR。最后说一句存储过程。课设里把CRUD写成存储过程是好习惯一方面参数化查询能防SQL注入另一方面SQL Server会缓存执行计划。但也要避免把所有业务都塞进数据库像“计算订单总价”这种简单逻辑放程序里比放库里更好维护。报告里提的“系统管理对花的采购和出售进行调度”我用一个存储过程把“售花扣库存”包起来这就是下一章要展开的。4. 关键模块实现登录权限、增删改查与订单联动4.1 登录与权限分配先建用户再给权限“权限分配”这个需求落到实处就是SQL Server的登录名和数据库用户两层。登录名管能不能连SQL Server数据库用户管能不能访问FlowerShop里的表。-- 在master库创建登录名密码按策略设置 USE master; CREATE LOGIN shop_admin WITH PASSWORD NAdmin2024; USE FlowerShop; -- 数据库用户映射到登录名 CREATE USER shop_admin FOR LOGIN shop_admin; -- 加入db_owner角色拥有全部操作权限 ALTER ROLE db_owner ADD MEMBER shop_admin;第一行CREATE LOGIN在master库里建登录名WITH PASSWORD后面是密码。然后切到FlowerShop库CREATE USER把登录名映射成数据库用户最后加入db_owner角色。如果只是给店员不应该给db_owner而是单独给增删改查权限-- 店员账号只授权花表和订单表的DML权限 CREATE LOGIN shop_clerk WITH PASSWORD NClerk2024; USE FlowerShop; CREATE USER shop_clerk FOR LOGIN shop_clerk; GRANT SELECT, INSERT, UPDATE, DELETE ON dbo.Flower TO shop_clerk; GRANT SELECT, INSERT ON dbo.OrderInfo TO shop_clerk;GRANT后面跟着权限列表ON后面是对象TO后面是用户名。这样店员能操作花和订单但改不了用户表。程序的登录模块只做一件事接收用户名和密码检查映射关系然后返回当前用户拥有的权限列表。如果用户直接用sa直连就绕过了这层设计答辩时被问权限分配就卡壳。还要注意SQL Server默认只有Windows认证模式不让你用SQL账号登录。需要右键实例→属性→安全性→选择“SQL Server和Windows身份验证模式”然后重启SQL Server服务。这一步不设置前面创建的登录名全都连不上新手很容易在这一步反复报18456。4.2 花信息管理与顾客管理增删改查的标准写法报告的功能说明里提到“当用户填入所需的增删改信息时会出现相应的对话框显示操作成功”。这些对话框背后就是标准CRUD。以花信息为例我一般会写成存储过程因为C#或Java调用存储过程比拼SQL安全得多。-- 新增花返回新生成的FlowerID CREATE PROCEDURE usp_Flower_Insert FlowerName NVARCHAR(50), PurchasePrice DECIMAL(10,2), SalePrice DECIMAL(10,2), StockQty INT 0 AS BEGIN SET NOCOUNT ON; INSERT INTO dbo.Flower (FlowerName, PurchasePrice, SalePrice, StockQty) VALUES (FlowerName, PurchasePrice, SalePrice, StockQty); SELECT SCOPE_IDENTITY() AS NewFlowerID; END参数用开头类型要和表字段一致。StockQty带默认值0这样调用方只传三个参数也能用。SCOPE_IDENTITY()返回刚才插入的自增主键程序拿到这个值可以继续往订单明细里写。对应地更新也可以封装成存储过程套路一致-- 更新花信息按FlowerID定位防止批量更新 CREATE PROCEDURE usp_Flower_Update FlowerID INT, FlowerName NVARCHAR(50), PurchasePrice DECIMAL(10,2), SalePrice DECIMAL(10,2) AS BEGIN UPDATE dbo.Flower SET FlowerName FlowerName, PurchasePrice PurchasePrice, SalePrice SalePrice WHERE FlowerID FlowerID; END这个存储过程的关键点在于WHERE条件。很多课设写UPDATE时漏掉WHERE导致整张表的价格全被改掉这是删除更新类操作最严重的事故。UPDATE执行后程序通过ROWCOUNT判断影响行数等于0就提示“没有找到对应花”。查询模块不必用存储过程直接一个带WHERE的SELECT就行。但要注意用户输入的关键字要参数化不要做字符串拼接。比如“按名称查花”-- 参数化查询关键词从程序传入不直接拼SQL SELECT FlowerID, FlowerName, PurchasePrice, SalePrice, StockQty FROM dbo.Flower WHERE FlowerName LIKE keyword %;LIKE后面是参数而不是直接拼进去可以避免SQL注入。课设报告里不需要讲安全攻击细节但至少要让老师看到你懂得用参数化查询。4.3 销售订单与库存联动事务保住数据一致性“对花的采购和出售进行调度”是整个系统最核心的功能顾客下单一束花系统要做三件事——写入订单表、写入订单明细表、扣减库存。这三件事必须要么全成功要么全失败否则会出现“订单下了但库存没减”。-- 销售事务先写订单再写明细最后扣库存 BEGIN TRY BEGIN TRAN; INSERT INTO dbo.OrderInfo (CustomerID, OrderDate) VALUES (CustomerID, GETDATE()); DECLARE OrderID INT SCOPE_IDENTITY(); INSERT INTO dbo.OrderDetail (OrderID, FlowerID, Qty, SalePrice) SELECT OrderID, FlowerID, Qty, SalePrice FROM dbo.Flower WHERE FlowerID FlowerID; UPDATE dbo.Flower SET StockQty StockQty - Qty WHERE FlowerID FlowerID; COMMIT; END TRY BEGIN CATCH ROLLBACK; THROW; END CATCH;逻辑说明BEGIN TRAN开启事务COMMIT提交CATCH里ROLLBACK回滚。这样后两步如果报错第一步订单也会被撤销。参数说明CustomerID和FlowerID是传入参数OrderID用SCOPE_IDENTITY()拿到新订单号UPDATE扣库存时一定要加WHERE FlowerID FlowerID漏了会把整表更新掉。关于并发线上销售场景里两个顾客同时买同一束花可能把库存扣成负数。最简单的处理是给库存字段加CHECK约束再加一层保险-- 库存量不允许为负从物理上挡住超卖 ALTER TABLE dbo.Flower ADD CONSTRAINT CK_Flower_StockQty CHECK (StockQty 0);更严谨的做法是在UPDATE语句里加上WHERE StockQty Qty受影响行数为0就说明库存不足回滚并提示用户。课设能写到事务和CHECK约束已经能说明你理解了ACID。中途还要处理报告中的“销售管理”包含零售顾客买花记录。零售顾客可能没有建档此时可以新建一个“散客”记录或者把顾客姓名做成可空、电话可空。这都是细节但写进设计文档里会让方案更完整。5. 避坑课程设计最常见的五个数据库翻车点5.1 连接与权限登录失败和“对象名无效”先查环境坑一SQL Server登录失败18456。现象程序里用SQL账号连接一直报“用户登录失败原因: 该用户与可信SQL Server连接无关联”。原因实例没有开启混合身份验证模式或者登录名SID和数据库用户映射对不上。解决先到实例属性→安全性勾选“SQL Server和Windows身份验证模式”再用ALTER USER重新映射登录名例如ALTER USER shop_admin WITH LOGIN shop_admin;。这个坑是最常见的因为新建登录名之后直接建数据库用户有时SID会不一致尤其在数据库附加或还原之后。验证是否解决用SSMS以SQL账号重新登录能连上就说明映射成功。坑二查询时报“对象名失效”。现象明明在SSMS里能看到dbo.Flower表执行SELECT却报找不到对象。原因当前库不是FlowerShop或者表名前没加dbo。解决执行USE FlowerShop;或者写成SELECT * FROM FlowerShop.dbo.Flower;。很多课设把脚本文件打开直接跑默认连到master库于是表和存储过程建错了位置后面全串了。血泪经验每段脚本开头都写USE别依赖SSMS的下拉框。这两个坑是环境问题不是逻辑问题。如果报错集中在权限和连接上先不要怀疑代码把SSMS的当前库和登录账号检查一遍。5.2 表设计与SQL中文乱码、主键重复、日期格式三连坑坑三中文显示为“???”。现象插入“玫瑰”后表里显示三个问号。原因列类型是VARCHAR而不是NVARCHAR或者插入的字符串前面没加N。解决建表把名称、地址等文本列全部改为NVARCHAR插入时用N玫瑰。SQL Server里N前缀表示Unicode字符串不加NVARCHAR会按系统代码页转换导致乱码。验证是否解决重新插入一条带中文的记录用SELECT查出来正常显示即可。坑四主键重复无法插入。现象自增主键的表插入时偶尔报“违反PRIMARY KEY约束”特别是程序跑第二次时。原因程序误传了主键值或者用了SET IDENTITY_INSERT ON后值没管理好。解决主键全部用INT IDENTITY程序插入时不显式传主键需要批量导入历史数据时才打开IDENTITY_INSERT用完立刻关闭。验证是否解决连续插入三条记录主键值为1、2、3且不报错说明自增正常。坑五日期格式不认。现象程序传“2024/05/01”可以“2024-05-01 14:30”报错还有“字符串转换日期失败”之类的消息。原因SQL Server的日期解析受SET DATEFORMAT、登录语言和区域设置影响字符串和DATETIME互相转换时最易翻车。解决统一用参数化查询传DATETIME类型程序端用datetime变量而不是字符串如果一定要写字面量用CONVERT(DATETIME, 2024-05-01, 120)120是ODBC规范日期格式。验证是否解决用不同格式的日期各查一次全部返回正常结果。这五类坑不只出现在花店系统。凡是涉及SQL Server的课设基本都绕不开。我检查别人项目时第一件事就是看文本字段是不是NVARCHAR第二件事就是看有没有IDENTITY第三件事是看有没有USE库。这三个地方守住一半问题就没了。6. 验证与进阶从报告到可运行系统的检查清单6.1 从报告到运行五分钟自查清单把课设报告变成可运行系统中间隔着很多细节。我整理了一张自查清单照着走一遍可以少交一次“无法运行”的作业。检查项操作通过标准ER图与表结构一致对照概念模型的实体检查每个实体是否有一张表没有“有实体无表”或“有表无实体”主外键完整查看外键约束试插入一条非法订单外键拒绝非法CustomerID权限生效用shop_clerk登录尝试DROP TABLE返回权限不足库存防负用超出库存的数量下单事务回滚库存不变数据字典齐全每张表字段都有类型和说明新成员不用看代码就能理解字段含义6.2 进阶方向让课设变成简历项目如果还有余力可以在原报告基础上加三个东西视图、存储过程、报表。视图可以把“每个花的累计销量”这种高频查询固化下来存储过程把销售事务封装好报表用一条GROUP BY语句就够了-- 按花名统计累计销量倒序输出用于销售报表 SELECT FlowerName, SUM(Qty) AS TotalQty FROM dbo.OrderDetail OD JOIN dbo.Flower F ON OD.FlowerID F.FlowerID GROUP BY FlowerName ORDER BY TotalQty DESC;GROUP BY按花名分组SUM汇总数量ORDER BY倒序这就是最简销售排行。从那以后我每次拿到数据库课设题目都会强制先跑一遍那张自查清单再开始写代码。报告可以写得漂亮但数据库能不能跑靠的还是这些细节。希望帮到你。本文还有配套的精品资源点击获取