企业官网建设流程全解析

简介：《SQL数据库课程设计宾馆房间管理系统》是一份完整的课程设计报告，适合软件工程专业学生在数据库课程设计、毕业设计或相关实训中参考。文档以宾馆客房管理为业务场景，完整展现了数据库设计的全过程：从需求分析、数据流图与数据字典，到概念结构、逻辑结构与物理设计，再到SQL Server 2000中建库建表、设置约束和填充数据，最后给出C#.NET应用程序的概要设计与程序实现。压缩包内含1个doc文档，共293KB，按课程设计目的与要求、数据库设计、程序实现和课程设计总结四部分展开，覆盖了用户登录、客房类型管理、客房信息管理、入住登记、客户查询与结算等核心功能模块。目前已有139人学习浏览，适合需要提交课程设计报告或想了解SQL Server数据库应用开发的读者。

1. 这道题的精髓在一个「活」字：SQL数据库课程设计宾馆房间管理系统到底在考什么

课程设计拿到「SQL数据库课程设计宾馆房间管理系统.doc」这个题面，很多人的第一反应是打开Word开始排版封面、写需求分析。我在帮学生看作业时发现，真正拉开分数差距的从来不是文档页数，而是你建的表能不能扛住老师现场提问。这道题的核心是数据库课程设计，宾馆房间管理只是载体——房间、客户、预订、入住、退房这几条业务线恰好覆盖了关系建模、外键约束、事务处理、统计查询这些数据库课的必考点。适合谁？适合正在做课程设计、需要一份能落地复现的建表思路与SQL脚本参考的人。下面这套方案用SQL Server 2022和SSMS演示，SQL Server 2019也能直接跑。

2. 从ER图到建表脚本：把房间、客户、订单三组核心表拆干净

2.1 房间类型独立成表：为什么用两个表而不是一个字段

第一版设计里最常见的翻车是把「房间类型」做成一个varchar字段，比如room_type varchar(20)，标准间、大床房直接写在客房表里。这样做的直接后果是：房价、床位数、可加床数这些跟着类型走的属性全部冗余在每一行客房记录里。老师只要问一句「如果豪华间要涨价，你要UPDATE多少行」，这个设计就扣分。

正确的做法是把客房类型拆成单独的表room_type，客房表通过room_type_id关联。这个拆分意味着「房间类型」是主表、「客房」是子表，符合第三范式的思路，避免类型属性的传递依赖。课程设计不一定要求达到3NF，但至少「类型」这种会被重复引用且有独立属性的名词，值得拥有自己的表。

-- 房间类型表 CREATE TABLE dbo.room_type ( room_type_id int IDENTITY(1,1) PRIMARY KEY, type_name nvarchar(30) NOT NULL UNIQUE, -- 标准间、大床房、套房 base_price decimal(10,2) NOT NULL, -- 门市价，算房费时的基准 bed_count tinyint NOT NULL DEFAULT 2, -- 默认双床 can_add_bed bit NOT NULL DEFAULT 0 -- 是否允许加床 );

这里的关键参数在于：IDENTITY自增当主键，type_name加UNIQUE防止类型重复录入造成「标准间」和「标准间 」并存；base_price用decimal(10,2)而不是float，因为涉及金额、要避免浮点误差；can_add_bed是bit类型，只存0/1，便于后续做加床费计算。

2.2 四张核心表的最小建表SQL

把宾馆管理系统按业务流拆开，最少需要四张表：客房表（room，记录每一间物理房间）、客户表（customer，记录客人信息）、预订表（reservation，记录预订行为）、入住登记表（stay，记录实际入住与退房），再加一张账单表（billing）用于退房结算。下面的脚本是能跑通的最小集合。

CREATE TABLE dbo.room ( room_id int IDENTITY(1,1) PRIMARY KEY, room_no varchar(10) NOT NULL, floor_no tinyint NOT NULL, room_type_id int NOT NULL REFERENCES dbo.room_type(room_type_id), room_status char(1) NOT NULL DEFAULT 'F', -- F空闲 O占用 R已预订 C打扫中 room_note nvarchar(200) NULL ); CREATE TABLE dbo.customer ( customer_id int IDENTITY(1,1) PRIMARY KEY, customer_name nvarchar(50) NOT NULL, id_card varchar(18) NOT NULL UNIQUE, phone varchar(20) NULL, create_time datetime NOT NULL DEFAULT GETDATE() ); CREATE TABLE dbo.reservation ( reservation_id int IDENTITY(1,1) PRIMARY KEY, customer_id int NOT NULL REFERENCES dbo.customer(customer_id), room_id int NOT NULL REFERENCES dbo.room(room_id), checkin_date date NOT NULL, checkout_date date NOT NULL, reserve_time datetime NOT NULL DEFAULT GETDATE(), status char(1) NOT NULL DEFAULT 'R', -- R有效 C已取消 I已入住 E已离店 remark nvarchar(200) NULL ); CREATE TABLE dbo.stay ( stay_id int IDENTITY(1,1) PRIMARY KEY, customer_id int NOT NULL REFERENCES dbo.customer(customer_id), room_id int NOT NULL REFERENCES dbo.room(room_id), checkin_time datetime NOT NULL, checkout_time datetime NULL, actual_price decimal(10,2) NULL );

简单说明每一张表存在的理由：room里用room_status区分F/O/R/C四种状态，这是后面处理「一个房间不能被预订两次」的基础；customer里给id_card加了UNIQUE，防止同一个身份证被录入两次形成脏数据；reservation里只存预期日期和状态，把实际的入住时间放在stay表，这样预订未到、提前离店都能通过状态变更记录；stay表保存checkin和checkout两个时间点，房费计算依赖它。

这里有一个容易忽略的设计问题：为什么stay表不直接放一个reservation_id外键？因为散客直接到店入住时并没有预订记录，如果stay.reservation_id设置NOT NULL外键，散客就根本入不了住。所以stay表用独立的stay_id做主键，通过customer_id和room_id与相关表关联，两条入住路径都能覆盖。

2.3 外键、默认值、约束怎么选：自增ID与GUID各有利弊

课程设计里最常见的争论是主键用int自增还是uniqueidentifier（GUID）。老师的标准答案通常两者都接受，但报告里如果写「GUID适合分布式」却用一张int自增的表去讲，就会在答辩时被追问。建议课程设计用int IDENTITY，原因有三：一是外键关联书写简单；二是排序就是入住顺序、方便调试；三是SQL Server教材案例几乎都以int自增为主。只有在「预订号需要对外不可猜测」这类点缀场景，才给reservation加一个GUID列做备用标识。

默认值方面，状态字段用char(1)配合DEFAULT能明显减少应用层漏写状态导致的脏数据。上面room表的room_status默认'F'、reservation的status默认'R'，都是让数据库兜底。注意约束命名：如果不在建表时给约束起名，SQL Server会自动生成一堆类似FK__reservati__room__2B3DB7D5的名字，排错时非常难看。建议在正式交付脚本里统一写成：

ALTER TABLE dbo.reservation ADD CONSTRAINT FK_reservation_room FOREIGN KEY (room_id) REFERENCES dbo.room(room_id);

再补一个索引的话题。课程设计能主动谈索引，是加分项。查询条件里常出现room_status、reservation.checkin_date、reservation.checkout_date、stay.checkout_time，这些列适合建非聚集索引；而外键列room_id、customer_id在JOIN时会频繁参与匹配，也应该建索引。SQL Server不会自动为外键建索引，数据量一大，JOIN的性能就露馅。课程设计里可以给reservation表的checkin_date和checkout_date建一个复合索引：

CREATE INDEX IX_reservation_date_range ON dbo.reservation (checkin_date, checkout_date) INCLUDE (room_id, customer_id, status);

这个复合索引直接服务于「查某段时间内哪些房间被占」的区间重叠查询。INCLUDE把查询要返回的列塞进索引叶节点，避免回表，算是一个小而精的性能优化点。

3. 增删改查之外：预订、入住、换房、退房四个关键业务点的SQL实现

3.1 预订到入住的状态机：用状态字段而不是删记录

宾馆房间管理系统的操作不是只做增删改查，预订流程要求你把状态变化管理好。常见做法是给reservation一个status字段，通过UPDATE状态值来流转：R有效 -> I已入住 / C已取消；入住后再由stay表记录离店时间，reservation的status改成E。千万不要在客户取消预订时执行DELETE，这会丢掉审计信息，答辩时「为什么要保留取消记录」也是一个加分回答点。

预订时的核心业务规则是「不能预订已被占用或已被预订的房间」。这个检查不能只靠应用层，数据库层要能用一条查询验证：

-- 检查room_id=12在2025-06-01到2025-06-03之间是否可订 SELECT COUNT(*) FROM reservation WHERE room_id = 12 AND status IN ('R','I') -- 有效预订或已入住都占房 AND checkin_date < '2025-06-03' -- 已有预订的入住日早于新退房日 AND checkout_date > '2025-06-01'; -- 已有预订的退房日晚于新入住日

这段查询用的是区间重叠判断：两条时间区间[A,B)和[C,D)重叠的条件是A<D且C<B。COUNT为0才能插入新预订。如果不做这个判断，同一间房就能被预订两次，这在宾馆业务里是严重翻车。为了防止并发下两个事务同时查到0，可以在插入前用UPDLOCK提示，或者给「房号+状态+日期范围」加一个唯一约束兜底，课程设计讲到事务时提一句就行。

3.2 入住登记：从预订转入住与直接入住两条路径

入住分成两种情况。第一种是客人有预订，前台找到reservation后把状态从R改成I，同时在stay表插入一条记录；第二种是散客直接到店，不经过reservation，直接向stay表插入记录并同步把room的room_status改成'O'。两条路径都要保证「房间状态与入住记录一致」，否则就会出现房间显示空闲但实际有人住的脏状态。

把这两步放进一个事务里执行，是课程设计里体现事务ACID的最佳位置：

BEGIN TRANSACTION; -- 步骤1：更新预订状态为已入住 UPDATE dbo.reservation SET status = 'I' WHERE reservation_id = 10086 AND status = 'R'; -- 条件里带原状态，避免重复办理 -- 步骤2：插入入住记录 INSERT INTO dbo.stay (customer_id, room_id, checkin_time) SELECT customer_id, room_id, GETDATE() FROM dbo.reservation WHERE reservation_id = 10086; -- 步骤3：把房间置为占用 UPDATE dbo.room SET room_status = 'O' WHERE room_id = (SELECT room_id FROM dbo.reservation WHERE reservation_id = 10086); COMMIT TRANSACTION;

这里的关键参数是GETDATE()，它取的是数据库服务器时间而不是前台电脑时间。多台电脑共用一套数据库时，用GETDATE()才能保证所有入住时间以服务器为准。UPDATE语句中AND status='R'是防重复办理的关键：两个前台同时操作同一笔预订时，只有第一个UPDATE会匹配到行，第二个影响行数为0，后续可以通过@@ROWCOUNT判断是否要回滚。

注意：UPDATE影响行数为0时，要用IF @@ROWCOUNT = 0执行ROLLBACK，否则事务会在无变化的情况下直接提交，形成「看似成功、实际没办成」的半截操作。

配合TRY...CATCH回滚的写法，可以作为课程设计报告中的「并发控制」小节素材。

3.3 换房操作：一次更新还是写换房记录

换房的常见实现是「原房间退、新房间住」，也就是把stay表原记录的checkout_time补上，再插入一条新记录。另一种做法是直接UPDATE stay.room_id，但老师如果问「你如何追溯客人住过哪几间房」，直接更新就答不上来。建议课程设计里用前一种，理由是它保留了完整住宿历史，也能算出每间房的实际入住率。

BEGIN TRANSACTION; -- 原房间退 UPDATE dbo.stay SET checkout_time = GETDATE() WHERE stay_id = 20001 AND checkout_time IS NULL; -- 房间状态还原 UPDATE dbo.room SET room_status = 'F' WHERE room_id = (SELECT room_id FROM dbo.stay WHERE stay_id = 20001); -- 新房间入住 INSERT INTO dbo.stay (customer_id, room_id, checkin_time) SELECT customer_id, 88, GETDATE() FROM dbo.stay WHERE stay_id = 20001; -- 新房间置为占用 UPDATE dbo.room SET room_status = 'O' WHERE room_id = 88; COMMIT TRANSACTION;

注意换房会改变房价，如果新房间类型不同，退房结算时要以新房间的房型价格为准。所以结算时actual_price应该从room_type.base_price重新计算，而不是沿用第一次入住时的价格。这个问题属于隐藏业务规则，报告里写清楚能显得考虑周全。

3.4 退房结算：房费计算与账单生成

房费计算是整个系统最容易被忽略的部分。用DATEDIFF算天数时，当天入住当天走算一天还是两天？超过中午12点算不算半天？课程设计不需要实现那么细的计费策略，但至少要给出一个不产生负数的可靠算法。常见做法是：按天计费，不足一天按一天；用DATEDIFF(day, ...)加1得到最小房费天数。

DECLARE @stay_id int = 20001; DECLARE @nights int; SELECT @nights = DATEDIFF(day, checkin_time, COALESCE(checkout_time, GETDATE())) + 1 FROM dbo.stay WHERE stay_id = @stay_id; -- 生成账单 INSERT INTO dbo.billing (stay_id, nights, room_price, total_amount, bill_time) SELECT s.stay_id, @nights, t.base_price, @nights * t.base_price, GETDATE() FROM dbo.stay s JOIN dbo.room r ON s.room_id = r.room_id JOIN dbo.room_type t ON r.room_type_id = t.room_type_id WHERE s.stay_id = @stay_id; -- 释放房间 UPDATE dbo.room SET room_status = 'F' WHERE room_id = (SELECT room_id FROM dbo.stay WHERE stay_id = @stay_id); UPDATE dbo.stay SET checkout_time = GETDATE(), actual_price = @nights * t.base_price FROM dbo.stay s JOIN ... WHERE s.stay_id = @stay_id;

这段脚本想说明的是：COALESCE(checkout_time, GETDATE())用来处理「客人还没退房但你要算截止目前房费」的场景，避免NULL参与运算得到NULL；@nights先算出来存入变量，避免后面多处重复计算。实际工作中还会有钟点房、协议价、早餐费，课程设计用「房费=房型价格x天数」就够，但要在报告里写明边界——「本设计按整天计费，不考虑钟点房与延时退房」。

4. 初始化数据与演示脚本：让答辩演示不再手忙脚乱

4.1 视图准备：在住客人、当日预订、房间占用统计

答辩现场最忌讳的是临时敲SQL、敲错字段名尴尬半天。常见做法是在课程设计里提前写好三个视图，演示时直接SELECT视图名就能出结果。这几个视图也是报告中「数据库设计」一章的配图素材。

视图一，在住客人：

CREATE VIEW vw_current_guest AS SELECT r.room_no, c.customer_name, c.id_card, s.checkin_time, DATEDIFF(day, s.checkin_time, GETDATE()) + 1 AS already_days FROM dbo.stay s JOIN dbo.room r ON s.room_id = r.room_id JOIN dbo.customer c ON s.customer_id = c.customer_id WHERE s.checkout_time IS NULL;

视图二，当日应到预订：

CREATE VIEW vw_today_reservation AS SELECT r.room_no, c.customer_name, c.phone, res.checkin_date, res.checkout_date FROM dbo.reservation res JOIN dbo.room r ON res.room_id = r.room_id JOIN dbo.customer c ON res.customer_id = c.customer_id WHERE res.status = 'R' AND res.checkin_date <= CAST(GETDATE() AS date) AND res.checkout_date > CAST(GETDATE() AS date);

视图三，房间占用统计，按类型汇总：

SELECT t.type_name, COUNT(*) AS total_rooms, SUM(CASE WHEN r.room_status = 'O' THEN 1 ELSE 0 END) AS occupied_rooms, SUM(CASE WHEN r.room_status = 'R' THEN 1 ELSE 0 END) AS reserved_rooms FROM dbo.room r JOIN dbo.room_type t ON r.room_type_id = t.room_type_id GROUP BY t.type_name;

前两个视图解决「现场演示数据不匹配」的窘境：老师抽查某间房时，视图里能看到当前谁在住。第三个统计视图用SUM+CASE实现条件计数，这是SQL里统计占用率的标准写法。注意视图三要GROUP BY t.type_name，否则聚合会混成一行。视图本身不占存储空间，每次查询实时计算，演示时数据变了结果也跟着变，不需要刷新。

4.2 存储过程：把预订与退房做成可复用的入口

课程设计如果只在查询分析器里手写SQL，老师的观感会差一截。把核心操作包成存储过程，既体现对数据库编程的掌握，也让演示流程变成「调用过程-查看结果」两步。下面给出预订房间的存储过程骨架。

CREATE PROCEDURE usp_create_reservation @customer_name nvarchar(50), @id_card varchar(18), @phone varchar(20), @room_id int, @checkin_date date, @checkout_date date, @new_reservation_id int OUTPUT AS BEGIN SET NOCOUNT ON; -- 这里可以根据需要先做时间重叠检查，参考3.1的区间重叠条件 INSERT INTO dbo.customer (customer_name, id_card, phone) VALUES (@customer_name, @id_card, @phone); INSERT INTO dbo.reservation (customer_id, room_id, checkin_date, checkout_date) VALUES (SCOPE_IDENTITY(), @room_id, @checkin_date, @checkout_date); SET @new_reservation_id = SCOPE_IDENTITY(); END;

参数里最需要注意的是OUTPUT参数@new_reservation_id。之前有同学用SELECT @@IDENTITY返回新ID，在触发器存在时会拿到错误值，SCOPE_IDENTITY()只返回当前作用域生成的ID，这是课程设计必须掌握的细节。SET NOCOUNT ON要加在BEGIN后面，它关闭受影响行数消息，否则某些客户端会多返回一条无意义的计数结果。

提示：退房结算的存储过程也建议包一层，把3.4的手写逻辑变成过程调用。演示时先调用usp_checkout 20001，再SELECT账单表，整个退房过程就不需要现场编写SQL。

4.3 演示数据怎么插：数量、覆盖场景与日期边界

演示数据是课程设计里最容易随便糊弄的部分。插三条数据就交差的库，老师一执行统计查询就露馅。建议至少准备30间房、8种房型、20位客人、15笔预订加8条入住记录，日期跨当前日期前后各一周，这样「在住客人」「当日应到」「逾期未到」「即将离店」这些查询全都有数据支撑。

插入演示数据的SQL要写成可重复执行的脚本。常见做法是开头判断表是否已有数据，有数据就清理重来。由于表之间有外键，删除顺序必须从子表开始，按billing -> stay -> reservation -> customer -> room -> room_type的顺序DELETE，最后再用DBCC CHECKIDENT把自增ID复位。这一步在报告里属于「测试数据准备」，写清楚能让老师觉得你考虑过初始化流程。

批量生成客户数据可以用集合运算代替一条条INSERT：

INSERT INTO dbo.customer (customer_name, id_card, phone) SELECT TOP 20 '测试客' + CAST(ROW_NUMBER() OVER (ORDER BY object_id) AS varchar(10)), '11010119900101' + RIGHT('0000' + CAST(ROW_NUMBER() OVER (ORDER BY object_id) AS varchar(4)), 4), '1380000' + RIGHT('0000' + CAST(ROW_NUMBER() OVER (ORDER BY object_id) AS varchar(4)), 4) FROM sys.objects;

这里用系统表sys.objects当数字发生器生成20行，配合RIGHT补零产生可读的身份证后四位和手机号后四位。课程设计里可以解释为「用集合操作代替循环插入」，这比写WHILE循环更符合SQL的思维方式。批量插入房间号同理：

INSERT INTO dbo.room (room_no, floor_no, room_type_id, room_status) SELECT '10' + RIGHT('0' + CAST(n AS varchar(2)), 2), 1, 1, 'F' FROM (SELECT TOP 30 ROW_NUMBER() OVER (ORDER BY object_id) AS n FROM sys.objects) temp;

这段产生1001到1030的房间号，把30间房全放在1层、类型指向1号类型。实际使用时可以把room_type_id和floor_no改成周期性变化的表达式，让数据分布更接近真实宾馆。

5. 课程设计避坑指南：从连接失败到外键冲突的5个高频问题

5.1 连接失败：SQL Server用sa登录报错18456

现象：学生机装完SQL Server，用sa账号登录SSMS时提示「用户'sa'登录失败。错误18456」。课程设计的演示环境最容易卡在这一步，因为多数教材默认用Windows身份验证安装，根本没有启用SQL Server身份验证模式。

原因：SQL Server默认的身份验证模式是Windows身份验证，sa账号默认被禁用，且安装时如果没有设置混合模式，SQL账号无法登录。

解决：先用Windows身份验证连入SSMS，右键服务器属性 -> 安全性 -> 选择「SQL Server和Windows身份验证模式」；再到安全性 -> 登录名 -> sa，启用登录并设置密码；最后右键服务器选择重启SQL Server服务。这里有个细节：修改身份验证模式后需要重启服务才生效，很多同学改了模式不重启，继续报同样的错。

ALTER LOGIN sa ENABLE; ALTER LOGIN sa WITH PASSWORD = 'YourStrongPassword123';

5.2 中文乱码：插入的中文变成问号

现象：INSERT中文后SELECT出来全是?，建表时明明用了nvarchar，为什么还是乱码。

原因：客户端连接与服务器排序规则不一致。SQL Server的排序规则（Collation）决定字符集与比较规则，客户端以GBK或UTF-8发送中文时，如果数据库排序规则为SQL_Latin1_General_CP1_CI_AS，非英文字符就无法正确存储。

解决：建库时指定中文排序规则Chinese_PRC_CI_AS，或者至少在连接字符串里加CharacterSet=UTF-8；字段一律用nvarchar/nchar而不是varchar，varchar存中文在某些排序规则下会丢字符。检查排序规则用：

SELECT DATABASEPROPERTYEX(DB_NAME(), 'Collation');

如果已经建好库，可以用ALTER DATABASE修改默认排序规则，但注意已存在的表字段不会自动跟随，需要逐列ALTER。课程设计遇到乱码时，最快路径是重建库并在CREATE DATABASE语句里带上COLLATE Chinese_PRC_CI_AS。

5.3 删除失败：删不掉房间类型，外键约束冲突

现象：想把room_type里一条测试数据删除，SSMS报错「DELETE语句与REFERENCE约束FK_room_room_type冲突」，删不了。

原因：room表仍有记录引用room_type_id，外键约束禁止删除被引用数据。很多同学第一次遇到时选择「禁用外键约束」来绕过，这是课程设计里的禁忌：禁用约束等于放弃完整性，后续演示一旦出现孤儿数据就会被老师追问。

解决：先删除子表引用数据，或先把这个房间类型下的房间换到别的类型，再删类型记录。正确顺序是先处理room，再处理room_type。如果把「先子后父」的删除顺序写进初始化脚本，能避免演示时现场手动点半天。

5.4 查询结果翻倍：JOIN之后COUNT数字不对

现象：统计客户数量时，SELECT COUNT(*) FROM customer得到20，但把customer和reservation JOIN后COUNT得到36，数据被放大。

原因：一个客户有多条预订，JOIN会让父表的行在结果里重复出现次数等于子表匹配次数。这是SQL新手最容易踩的坑，也是答辩时老师最爱问的「为什么记录数变多了」。

解决：先JOIN得到明细列表没问题，但统计客户数要基于customer表本身。写COUNT(DISTINCT c.customer_id)也能修正，但更本质的解法是意识到聚合与JOIN的粒度差异。课程设计报告里如果出现这种问题，解决过程本身就可以写成排查记录。

5.5 时间比较出错：把'2025-06-01'当字符串比较

现象：WHERE checkin_date > '2025-06-01' 查出来的结果不对，边界日期多一天或少一天。

原因：当列类型是datetime或date时，字符串与日期比较会隐式转换，但'2025-06-01'被转成2025-06-01 00:00:00，如果checkin_time里有2025-06-01 08:30这样的时间值，它就不满足「大于」条件，边界数据被漏掉。

解决：明确写清楚边界语义。查询6月1日当天及之后的记录，用checkin_date >= '2025-06-01'；查「6月1日整天」则用checkin_date >= '2025-06-01' AND checkin_date < '2025-06-02'。几乎所有统计查询的日期边界问题都能归结到半开区间这一点上，把这个原则写进报告，比堆十条SQL技巧更能让老师认可。

6. 把报告和答辩讲明白：ER图、数据流与关键SQL讲解的进阶技巧

课程设计的交付物里，最容易被低估的是ER图和业务流图的表达方式。不必用专业建模工具，直接在报告里画清楚表关系也能讲明白，但要遵循一个原则：ER图中的实体必须和你代码里CREATE TABLE的表一一对应。把room_type、room、customer、reservation、stay、billing六张表画成方框，连线标注「1:N」「1:1」关系，这张图就是答辩的主心骨。老师从ER图切入的第一个问题，往往是「为什么预订表要关联到具体房间而不是房间类型」，顺着这条线就能带出前面讲过的「当前预订必须占住一间具体房号」的设计考量。

推荐的讲解路径是十分钟流程：先讲ER图说明设计思路，再用SSMS执行4.1的视图查在住客人，接着调用4.2的存储过程演示一次预订与一次退房，最后翻到报告里的状态字段取值表说明设计取舍。整个过程不要超过十分钟，留出时间给老师提问。常见提问和回答要点可以提前列一张表。

我自己的习惯是，交报告前一天把所有SQL脚本从头到尾重新执行一遍，并找一台干净环境的电脑测试连接。数据库课程设计的技术含量大部分集中在建表和事务设计里，报告里忠实地写清楚你踩过的坑和解决方式，比堆页数更有说服力。希望帮到你。

本文还有配套的精品资源，点击获取