Noamwa数据库课程设计这个环节，十个同学里少说有六七个会选管理系统，而管理系统里最经典、最不容易翻车的题目之一就是酒店管理系统。它好在哪？实体关系清楚、业务逻辑完整、既能体现增删改查的基本功，又有视图、存储过程、事务处理这些能拿得出手的深层内容，配合学校课程里最常见的 MySQL + VB.NET 组合，整套做下来既不会太简单显得敷衍，也不至于复杂到做不完。这篇文章我就按自己做课设到后来带项目的经验，把这个题目从表结构设计、MySQL端实现到VB.NET连接调用，一步步拆开讲清楚，最后把我踩过的坑和答辩常被追问的问题也一并整理出来，给正在做或者准备选这个题的同学一条能直接照着走的路。
1. 系统设计与数据库建模：动手建表前先想清楚这些事
大部分同学做课设有个通病：打开 MySQL 就开始敲 CREATE TABLE，表建到一半发现少了字段，后面前端代码写完了发现数据结构不合理，又回头改表，整个开发过程反复折腾。所以我把设计阶段放到最前面说，这部分想清楚了，后面写代码会顺很多。
1.1 酒店业务到底有哪些核心流程
酒店管理系统不是一个简单的“房间表 + 客户表”就能糊弄过去的。你把自己代入前台接待员的角色，把一天的工作流程走一遍，系统要支持什么就很清楚了。
客人来了先问有没有房，这涉及“根据房型、日期、价格查可订房间”；客人决定入住，要登记身份信息、收押金、分配房间、把房间状态从“空闲”改成“占用”；住到一半可能换房、续住，这涉及订单修改和房间状态联动；退房时要算房费、算消费（比如早餐、超市商品、损坏赔偿），要结账并打印明细；晚上下班前，前台要把当天的入住率、营业额汇总给经理看。这些流程对应的核心数据就是：房间、客户、订单、入住记录、账单、员工。
搞明白这些之后你会发现，酒店管理系统实际上是一个典型的“状态流转”系统：房间在不同状态下流转，订单在不同状态下流转，账单在不同状态下流转。设计表的时候，必须保证每一次状态变化都有记录、能追溯，而不是直接 UPDATE 覆盖掉旧数据。这一点做到位了，数据库设计这部分就已经超过大部分课设作品了。
1.2 表结构设计：核心表怎么拆出来的
我在这个项目里最终落地的表一共 8 张，下面按“基础数据 → 业务数据 → 辅助数据”三个层次逐个说明。
房间表 room 是基础中的基础。字段包括 room_id 房间编号、type_id 房型编号、floor 所在楼层、status 当前状态、price 门市价、remark 备注。其中 status 用 TINYINT 表示：0 空闲、1 占用、2 维修、3 已预订。这里要注意一个常见的错误，就是直接用 VARCHAR 存“空闲”“占用”这些中文字段，这样做不是不行，但做条件查询和统计时会很别扭，而且容易因为空格、全半角问题查出错误数据。用数字状态位，在代码里写一个枚举或者字典去映射，是更工程化的做法。
房型表 room_type 单独拆出来而不是把房型名直接写进房间表，是为了避免数据冗余。大床房、标准间、套房这些属性，如果每个房间都重复存一遍“大床房”三个字，占的空间虽小，但哪天要统一改房型名称或者给房型加“床位数”“面积”这些属性时，你就要连累房间表一起更新，很容易出错。拆成两张表，房间表只存 type_id，房型表维护名称和详细属性，这就是最简单的“数据规范化”思路。
客户表 customer 主要存客户身份信息：customer_id、name、id_card 身份证号、phone、member_level 会员等级、register_time 注册时间。这里有一个关键点：身份证号要设置 UNIQUE 唯一约束。实际业务里客人重复开房是常事，如果你不做唯一性约束，同一个身份证会在表里生成好几条记录，后续做会员积分、历史记录查询都会乱套。
订单表 reservation 和入住记录表 checkin 容易混淆，我在这里明确区分一下：reservation 管的是“预订”，即客人还没到店，先订好某天某房间；checkin 管的是“实际入住”，即客人已经到店办理了入住。很多课设把这两个概念合成一张表，虽然也能跑，但遇到“客人预订了却爽约没来”和“客人没预订直接上门入住”这两种情况时，一张表就说不清楚了。分开设计后，reservation 里有 status 字段标记订单状态（已预订/已入住/已取消/已完成），checkin 里则记录实际的入住时间、离店时间、入住天数。
账单表 bill 用来记录每一笔消费，包括房费、押金、其他消费、实收金额、结算方式、操作员工。账单明细表 bill_item 则用来记录消费明细，比如客人买了瓶矿泉水、加了床被子，每项单独一条记录。主表存汇总、明细表存条目，这种“主从表”结构在管理系统中非常常见，设计账务相关功能时几乎必然要用到。
员工表 employee 存系统登录账号、密码、真实姓名、角色、联系电话。密码字段不要明文保存，至少做一次 MD5 或 SHA 哈希再入库，这个细节虽然课设里不会深究，但写进设计文档和答辩时讲出来，会显得你比其他人专业得多。
还有一张操作日志表 operation_log，用来记录谁在什么时间做了哪个操作。这张表是纯辅助性质的，课设里不做也不会影响功能，但我建议加上。原因很简单：它是你答辩时说明“系统完整性”的加分项，而且实现起来也就多一个 INSERT 的事。
1.3 字段类型和约束的几个关键决策
很多同学建表时字段类型全凭感觉，比如金额随手就用 FLOAT，价格随手就用 INT。这里我必须强调一个原则：涉及钱的字段，绝对不要用 FLOAT 或 DOUBLE。原因很简单，浮点数在计算机内部是二进制近似存储，0.1 + 0.2 的结果是 0.30000000000000004，这在显示上可能看不出来，但金额一旦经过多次累加、折扣计算，误差就会累积到肉眼可见的程度。正确的类型是 DECIMAL(10,2)，它按字符串方式存储精确小数，完全不存在精度丢失问题。
时间字段方面，预订时间、入住时间、离店时间、操作时间，统一用 DATETIME 类型。不要用 VARCHAR 存时间字符串，因为你后续要按日期范围查询、要算入住天数，字符串比较和日期函数用起来都很别扭。TIMESTAMP 和 DATETIME 的区别在于时区处理和范围限制，课设场景下两者都可以，我个人习惯用 DATETIME，原因是不受 2038 年问题限制，也不用操心时区转换。
状态字段用 TINYINT 而不是 INT，因为 TINYINT 只占 1 字节，取值范围 -128 到 127，用来存状态码绰绰有余，还能从语义上暗示“这个字段只能放小数字”。主键方面，如果房间编号有明确业务含义（比如“501”表示 5 楼 01 号房），就用 VARCHAR 直接做主键；像客户编号、订单编号这类没有明确业务含义的，可以用自增 INT 做主键，同时给业务编号字段建唯一索引。
还有一个小细节：所有表都要加 create_time 和 update_time 两个审计字段。它们的作用是，将来排数据问题的时候能知道这条记录是什么时候创建、什么时候修改的。别小看这两个字段，我在实际项目中排查数据不一致问题，十次有八次靠它们定位到具体是哪条更新语句出了问题。
1.4 表关系与外键：该用的时候用，该省的省
表关系用一句话概括：房间表和房型表是多对一，订单表关联客户表和房间表，账单表关联入住记录表和员工表。
外键约束这事要分两头说。课设中导师通常希望看到外键，因为它能保证数据完整性——比如 checkin 表里不能插入一个不存在的 room_id，数据库层面就拦住了。但如果项目要上线、要面对高并发写入，外键会在每次插入更新时额外做完整性检查，影响性能，所以很多互联网公司反而会去掉物理外键，只在应用层维护逻辑关系。
课设场景我建议保留物理外键。原因一是符合教学预期，答辩时老师问到“数据完整性怎么保证”你可以理直气壮地说用外键约束；原因二是课设数据量小，性能影响完全可以忽略。但有一个坑要提前避开：设置外键时，如果 UPDATE 或 DELETE 违规，比如你删一个还有入住记录的客户，MySQL 会直接报错。合理做