企业官网建设流程全解析

简介：一份面向数据库课程设计、毕业设计及期末大作业场景的Python酒店管理系统完整方案。整个压缩包共61个文件、约8.3MB，其中包含18个Python源文件、17个pyc编译缓存、8个Qt Designer界面文件、3个SQL数据库脚本与2份PDF设计文档，覆盖从数据库初始化、业务代码到交互界面的全链路。代码内附详细注释，配合E-R关系图与功能结构图，初学者可快速理清客房预定、入住登记、退房结算、房态管理等核心模块；课程设计内容要求与系统设计报告两项文档，可用于对照写论文与答辩。下载后简单部署即可运行，目前已有382人学习下载，适合需要参考完整项目结构、文档规范与源码实现的学生直接复用或二次开发。

1. 数据库大作业里的酒店管理系统：先建表还是先写界面，答案和你想的不一样

不少同学拿到「基于Python的酒店管理系统」这个题目时，第一反应是先把登录窗口和房间表格画出来，等界面像模像样了再回头补数据库。这个顺序基本是血泪经验的源头：现场演示时前台点了几下，房态数据对不上，账单金额算错，退房后房间状态没有释放，数据库追问环节一句话答不上来。数据库是这套系统的地基，表结构、外键、事务与状态流转，直接决定验收结果；源代码和文档说明只是把设计落地的手段。本文按「数据模型→工程骨架→核心功能→避坑→验收加餐」的顺序，把一套可复现的方案讲完整，适合正在做课程大作业、希望获得稳定演示效果并写出完整文档说明的入门选手。

2. 数据模型先行：酒店管理系统的表结构与设计取舍

数据库设计文档是大作业交付物的核心组成部分，导师往往先翻数据字典再跑代码。先建表再写界面，意味着代码里所有状态的流转都有数据支撑，而不是临时在内存里维护一堆字典。这一章把表拆开讲明白，并给出可直接执行的建表脚本。

2.1 拆解核心实体：房间、客户、预订、入住、账单如何关联

酒店业务可以抽象成五个实体：房间、客户、预订单、入住单、账单。房间是资源，客户是主体，预订和入住是状态流转，账单是结算结果。再加上一个用户表用于登录，一共六张表。这六张表的关系是：一个客户可以有多条预订和多条入住记录，一间房在某段时间内只能被一个有效预订或入住占用，一张入住单最终对应一张账单。

预订单和入住单分开建模而不是合并，原因在于业务状态不同：预订可以取消，入住一旦建立就必须走退房结算流程；同时客户可以先预订、到店再办理入住，两个动作在时间上不一定是连续的。把两张单子合并成一张表，会导致「已预订但未到店」和「已入住」两种状态混在同一行里，统计时非常别扭。账单挂在入住单下，而不是挂在客户下，是因为一次入住只结算一次，金额按房价、天数和折扣计算，挂客户会导致多住多次时账单归属不清晰。

ER 关系在文档里通常画成矩形和连线，我这里用文字描述：room 与 reservation 是 1 对多，room 与 checkin 是 1 对多，customer 与 reservation 是 1 对多，customer 与 checkin 是 1 对多，checkin 与 bill 是 1 对 1。画 ER 图时注意把外键关系标在子表上，教材里的惯例是子表保存父表主键作为外键，大作业验收时这个细节常被单独提问。

2.2 选 MySQL 还是 SQLite：约束、事务与演示效果的三层对比

常见做法是 Python 连 SQLite 或 MySQL。SQLite 零配置、文件即库，适合快速原型；但大作业如果要求「数据库设计」占比较高，MySQL 更能体现约束、事务、权限和可视化工具操作。我的建议是：课程没有强制要求就用 MySQL 8.0，配合可视化客户端展示表结构和数据，答辩效果明显更好；只有环境装不上 MySQL 时才退回 SQLite。

两者的差异主要体现在三层。第一层是约束能力：MySQL 支持完整的外键约束、检查约束和多种索引类型，SQLite 默认外键约束是关闭的，需要每次连接执行PRAGMA foreign_keys = ON。第二层是事务与并发：MySQL 的 InnoDB 支持行级锁和多版本并发控制，模拟多个前台同时操作时表现稳定；SQLite 是库级锁，写入并发一高就报 database is locked。第三层是演示观感：MySQL 可以用可视化工具实时查看数据变化，导师追问时能直接看到行记录，这比打开一个 db 文件更有说服力。

下面是六张表的建表脚本。先建库，再建表，注意字符集统一用 utf8mb4，否则后面中文乱码问题会提前埋雷。

CREATE DATABASE IF NOT EXISTS hotel_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE hotel_db; CREATE TABLE room ( room_id INT AUTO_INCREMENT PRIMARY KEY, room_no VARCHAR(10) NOT NULL UNIQUE COMMENT '房间号，如 301', room_type VARCHAR(20) NOT NULL COMMENT '类型：单人间/标准间/套房', price DECIMAL(10,2) NOT NULL COMMENT '挂牌价，单位元', floor TINYINT NOT NULL COMMENT '楼层', status TINYINT NOT NULL DEFAULT 0 COMMENT '0-空闲 1-已预订 2-已入住 3-维修' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE customer ( customer_id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(50) NOT NULL, id_card VARCHAR(18) NOT NULL UNIQUE COMMENT '证件号，业务上应唯一', phone VARCHAR(20) NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这段 SQL 的关键点在于：room_no加了 UNIQUE，防止同一房间号重复录入；status用 TINYINT 而不是字符串，是为了查询走索引更快，同时配合代码里的枚举常量；id_card加 UNIQUE 能在数据库层兜底重复客户。COMMENT注释一定要写，后续生成数据字典文档时直接对照表结构看，省事很多。

预订、入住、账单三张表继续往下建。预订表里有个容易忽略的点：checkin_date和checkout_date是日期类型而不是时间戳，因为预订只精确到天；入住表的checkin_time才用 DATETIME。两套时间口径不能混，混了后面做日期冲突判断时会算错。

CREATE TABLE reservation ( reservation_id INT AUTO_INCREMENT PRIMARY KEY, customer_id INT NOT NULL, room_id INT NOT NULL, checkin_date DATE NOT NULL COMMENT '计划入住日期', checkout_date DATE NOT NULL COMMENT '计划离店日期', status TINYINT NOT NULL DEFAULT 0 COMMENT '0-待确认 1-已确认 2-已入住 3-已完成 -1-已取消', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, CONSTRAINT fk_res_customer FOREIGN KEY (customer_id) REFERENCES customer(customer_id), CONSTRAINT fk_res_room FOREIGN KEY (room_id) REFERENCES room(room_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE checkin ( checkin_id INT AUTO_INCREMENT PRIMARY KEY, reservation_id INT NULL COMMENT '由预订转入住则填写，直接上门则置空', customer_id INT NOT NULL, room_id INT NOT NULL, checkin_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, checkout_time DATETIME NULL, status TINYINT NOT NULL DEFAULT 1 COMMENT '1-在住 2-已退房', CONSTRAINT fk_ci_res FOREIGN KEY (reservation_id) REFERENCES reservation(reservation_id), CONSTRAINT fk_ci_customer FOREIGN KEY (customer_id) REFERENCES customer(customer_id), CONSTRAINT fk_ci_room FOREIGN KEY (room_id) REFERENCES room(room_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE bill ( bill_id INT AUTO_INCREMENT PRIMARY KEY, checkin_id INT NOT NULL, room_id INT NOT NULL, customer_id INT NOT NULL, days INT NOT NULL COMMENT '实际入住天数', amount DECIMAL(10,2) NOT NULL COMMENT '折前金额', discount DECIMAL(3,2) NOT NULL DEFAULT 1.00 COMMENT '折扣率', total DECIMAL(10,2) NOT NULL COMMENT '实付金额', pay_time DATETIME DEFAULT CURRENT_TIMESTAMP, pay_method VARCHAR(20) DEFAULT 'cash', CONSTRAINT fk_bill_checkin FOREIGN KEY (checkin_id) REFERENCES checkin(checkin_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

说明一下两个设计细节。checkin.reservation_id允许为空，是因为业务上存在「客人直接到店办理入住」的场景，没有预订也要能开单，如果把这个字段设为 NOT NULL，反而会把业务流程写死。bill冗余了room_id和customer_id，这在第三范式上属于冗余，但大作业阶段的账单表通常要支持独立查询，比如「某个客户今年消费了多少」，冗余两个字段能少做两次联表查询，代价是更新时必须保证一致，实际项目中这类冗余需要和导师提前说明理由。

2.3 数据字典文档：文档说明里最值钱的一页

文档说明是标题交付物的一部分，很多同学把文档写成「软件使用说明书」，教人点按钮，这不是数据库大作业要的东西。文档里最值钱的是数据字典，也就是每张表的字段级说明。导师翻文档时重点看三样：表之间关系是否讲清、字段类型和注释是否与建表脚本一致、有没有说明状态字段的取值含义。

数据字典用表格写最直观，以 room 表为例：

每张表配一个这样的表格，再把外键关系单独画一页说明，文档的数据库部分就算扎实了。状态字段的取值含义不要只写在表注释里，要在文档正文单独列一段「状态约定」，包括预订表的 5 种状态流转：待确认→已确认→已入住→已完成，任一状态都可流转到已取消。状态流转图画在文档里，代码里用枚举或常量对表，验收时被问到「状态存的是什么」就能直接答上来。

3. 工程骨架：Python 连接与操作数据库的代码底座

数据库设计好了，代码层的第一步不是写界面，而是把「连接、查询、提交、回滚」这套底座搭稳。很多大作业翻车就翻在到处pymysql.connect()裸连，每个页面开一个连接，跑久了连接数爆掉，或者忘记提交导致数据丢失。这一章给出一个可复现的工程骨架，并解释每个文件为什么这样放。

3.1 项目目录怎么摆：代码、SQL、文档三层分离

先看目录结构。我的习惯是代码、SQL 脚本、文档三层分离，各管各的，避免全部文件堆在根目录：

hotel_manager/ ├── app.py # 入口，负责初始化数据库并启动界面 ├── config.py # 数据库连接配置 ├── db.py # 连接封装与通用查询方法 ├── models/ │ ├── room.py # 房间相关操作 │ ├── customer.py # 客户相关操作 │ ├── reservation.py # 预订操作 │ └── bill.py # 入住、退房、账单操作 ├── views/ │ └── main_window.py # 主界面（Tkinter 或 PyQt 按环境选） ├── sql/ │ └── init.sql # 第 2 章的建库建表脚本 ├── docs/ │ ├── 需求说明.md │ ├── 数据库设计文档.md │ └── 使用说明.md └── requirements.txt

这个排列的核心逻辑是：sql/里的脚本是数据库的唯一事实来源，models/里只有业务逻辑和 SQL 语句，不掺界面代码；views/只负责把模型返回的数据渲染到界面。后续如果想把 Tkinter 换成 Web 界面，只需要替换 views 层，models 层原样复用。requirements.txt 里只需要写pymysql这一个第三方依赖，Tkinter 是 Python 标准库，不用写进去。

分层看起来多花了一点时间，但对大作业的好处是答辩时能清晰说出「我的代码分了数据层、业务层、界面层」，这比贴一整段 500 行的单文件脚本专业得多。单文件写法不是不行，但字段一多，改一个查询就要全局找引用，后期改 bug 的时间会成倍增加。

3.2 数据库连接层封装：单例连接与统一提交回滚

连接封装的目标很简单：整个程序生命周期只维护一个连接对象，查询方法统一处理游标和异常，写操作统一提交，出错统一回滚。常见做法是写一个 Database 类，构造时连库，提供query_all、query_one、execute三个方法。

# db.py import pymysql from pymysql.cursors import DictCursor class Database: """数据库连接与操作封装，程序全局共享一个实例""" def __init__(self, config): self.config = config self.conn = self._connect() def _connect(self): conn = pymysql.connect( host=self.config['host'], port=self.config['port'], user=self.config['user'], password=self.config['password'], database=self.config['database'], charset='utf8mb4', cursorclass=DictCursor, autocommit=False, # 关闭自动提交，写操作显式 commit ) return conn def query_all(self, sql, args=None): """查询多条记录，返回 list[dict]""" with self.conn.cursor() as cursor: cursor.execute(sql, args) return cursor.fetchall() def query_one(self, sql, args=None): """查询单条记录，没有则返回 None""" with self.conn.cursor() as cursor: cursor.execute(sql, args) return cursor.fetchone() def execute(self, sql, args=None): """执行写操作，成功后立即提交，返回受影响行数""" with self.conn.cursor() as cursor: rows = cursor.execute(sql, args) self.conn.commit() return rows def close(self): self.conn.close()

说明几个参数。cursorclass=DictCursor让查询结果变成字典列表，代码里写row['name']而不是row[1]，可读性好很多，也避免表结构调整后按下标取值取错。autocommit=False是刻意为之，配合execute方法里的commit()，保证每个写操作在同一处提交，不会出现这边 insert 了那边忘了 commit 的情况。事务性的多步操作（比如退房）不走这个execute方法，而是单独在一个方法里用conn.begin()和conn.commit()控制，后面第 4 章会展开。

with self.conn.cursor()的写法会自动关闭游标，但不会关闭连接。连接对象在整个程序里保持一个即可，不要每次查询都重新连接，频繁建连在演示时会导致窗口卡顿。如果界面线程和查询线程分离，还要考虑给连接加锁，或者干脆保持单线程操作数据库，大作业阶段单线程完全够用。

3.3 配置管理：账号密码与连接参数不写死在代码里

配置文件单独放一个config.py，好处是换机器、换数据库时只改一处。常见做法是把连接参数写成字典，代码里通过Database(config)传入。需要注意密码不要出现在任何提交给老师的源码截图里，用占位符代替。

# config.py config = { 'host': '127.0.0.1', 'port': 3306, 'user': 'hotel_app', 'password': 'your_password_here', # 替换为本地 MySQL 实际账号 'database': 'hotel_db', 'charset': 'utf8mb4', }

host写127.0.0.1而不是localhost，可以避开部分环境里 localhost 走 socket 而程序走 TCP 导致的连接不上的问题。port默认 3306，如果本机装的是 MySQL 8.0 的默认端口就不用改；用了自定义端口务必在这里同步。charset和建库时的DEFAULT CHARSET utf8mb4保持一致，这步不做，后面中文显示就会出乱码。

更稳妥的做法是用环境变量覆盖默认值，比如从os.environ读取，这样代码提交后即使别人看到配置结构也拿不到真实密码。大作业阶段可以在config.py里加一层判断：

import os config = { 'host': os.environ.get('DB_HOST', '127.0.0.1'), 'port': int(os.environ.get('DB_PORT', 3306)), 'user': os.environ.get('DB_USER', 'hotel_app'), 'password': os.environ.get('DB_PASSWORD', 'your_password_here'), 'database': os.environ.get('DB_NAME', 'hotel_db'), }

os.environ.get的第一个坑是把端口读出来是字符串，必须包int()，否则 pymysql 会直接报类型错误。第二个坑是.get的默认值仍然会把占位密码带进代码里，所以正式提交前要把默认密码去掉或改为空字符串，并写进 README 说明如何通过环境变量注入。这一层小节虽然代码量不大，但「配置与代码分离」在答辩里常被当作工程素养的加分点。

4. 核心业务流程：订房、入住、退房与账单的代码实现

模型和底座都齐了，接下来是评委关注的业务核心。酒店管理系统最容易被追问的是三段流程：预订时怎么避免同一房间重复卖出，退房时怎么保证账单金额与房态同步更新，统计报表的数据从哪来。这一章逐一给出可运行的实现，并说明状态机与事务的配合方式。

4.1 预订房间：时间冲突检查是第一个业务难点

预订的核心约束是「同一房间在同一时间段内不能有两个有效订单」。判断条件不能用简单的「相等」，而是区间重叠：新订单的入住日期要晚于已有订单的离店日期，或者新订单的离店日期要早于已有订单的入住日期，只有这两种情况才不冲突。写成 SQL 就是 NOT (已有订单离店 <= 新订单入住 OR 已有订单入住 >= 新订单离店)。

# models/reservation.py def check_room_available(db, room_id, checkin_date, checkout_date): """检查房间在指定日期区间是否可预订，返回 True 表示可用""" if checkin_date >= checkout_date: raise ValueError('离店日期必须晚于入住日期') sql = """ SELECT COUNT(*) AS cnt FROM reservation WHERE room_id = %s AND status IN (1, 2) AND checkin_date < %s AND checkout_date > %s """ row = db.query_one(sql, (room_id, checkout_date, checkin_date)) return row['cnt'] == 0

这段 SQL 的关键在status IN (1, 2)：只有「已确认」和「已入住」的预订才参与冲突判断，「待确认」和「已取消」的订单不占房，否则客户取消的订单会一直卡着房间卖不出去。checkin_date < %s和checkout_date > %s用参数传入的是目标订单的离店日和入住日，组合起来正好表示两个区间是否重叠。

创建预订时，先查可用，再插入记录，并且把房态更新为「已预订」。两步操作要放在一个事务里，防止并发场景下两个请求同时通过检查。常见做法是将整个预订逻辑包进一个方法，检查、插入、更新房间状态，最后统一提交。

# models/reservation.py from datetime import date def create_reservation(db, customer_id, room_id, checkin_date, checkout_date): """创建预订单，成功后返回 reservation_id""" if not check_room_available(db, room_id, checkin_date, checkout_date): raise Exception('该房间在此时间段已被预订，请更换房间或日期') try: db.conn.begin() with db.conn.cursor() as cursor: cursor.execute(""" INSERT INTO reservation (customer_id, room_id, checkin_date, checkout_date, status) VALUES (%s, %s, %s, %s, 1) """, (customer_id, room_id, checkin_date, checkout_date)) reservation_id = cursor.lastrowid cursor.execute(""" UPDATE room SET status = 1 WHERE room_id = %s AND status = 0 """, (room_id,)) db.conn.commit() return reservation_id except Exception as e: db.conn.rollback() raise e

这里有两个细节容易在答辩时被追问。第一，UPDATE room ... WHERE status = 0是乐观锁写法，更新影响行数为 0 说明房间状态已被其他操作修改，事务会回滚，避免覆盖别人的状态。第二，如果预订后客户迟迟不到店，系统里需要有「超时释放」逻辑，大作业阶段可以在查询可用房间时把超过预定入住日仍未入住的订单自动置为已取消，代码量不大但能体现思考深度。

4.2 入住与退房：用事务保证房态和账单不分裂

入住有两种来源：由预订转入，客户直接上门。对应到代码，预订转入时要把reservation.status改成 2（已入住），同时往checkin表插入一条记录，房态改成 2；直接上门则只插入checkin，房态从 0 直接变 2。退房是反向操作，也是最容易出错的流程：需要同时完成「算账单、更新入住单状态、释放房间」三件事，任何一步失败都不能留下一半数据。

# models/bill.py from datetime import datetime def checkout(db, checkin_id, discount_rate=1.0): """退房结算：生成账单并释放房间，三步操作在同一事务内完成""" try: db.conn.begin() with db.conn.cursor() as cursor: # 1. 取出在住记录和房价 cursor.execute(""" SELECT c.checkin_id, c.room_id, c.checkin_time, r.price, r.room_no FROM checkin c JOIN room r ON c.room_id = r.room_id WHERE c.checkin_id = %s AND c.status = 1 FOR UPDATE """, (checkin_id,)) row = cursor.fetchone() if not row: raise Exception('入住单不存在或已完成退房') # 2. 计算入住天数，至少按 1 天计 days = (datetime.now() - row['checkin_time']).days + 1 if days < 1: days = 1 amount = round(row['price'] * days, 2) total = round(amount * discount_rate, 2) # 3. 更新入住单为已退房 cursor.execute(""" UPDATE checkin SET checkout_time = NOW(), status = 2 WHERE checkin_id = %s """, (checkin_id,)) # 4. 插入账单 cursor.execute(""" INSERT INTO bill (checkin_id, room_id, customer_id, days, amount, discount, total, pay_time) VALUES (%s, %s, %s, %s, %s, %s, %s, NOW()) """, (checkin_id, row['room_id'], row['customer_id'], days, amount, discount_rate, total)) # 5. 房间释放为空闲 cursor.execute(""" UPDATE room SET status = 0 WHERE room_id = %s """, (row['room_id'],)) db.conn.commit() return total except Exception as e: db.conn.rollback() raise e

这段代码的三个关键点。FOR UPDATE是对查出的入住单加行锁，防止两个窗口同时对同一单退房，这在演示时用两个客户端同时操作就能看出区别。天数计算用(now - checkin_time).days + 1，是因为入住当天算一天，比如 1 号下午入住、3 号上午退房，实际住了 3 天，按自然日计费。NOW()在 SQL 里生成离店时间，与 Python 侧的datetime.now()可能在秒级有微小偏差，账单里只用 Python 侧算的天数和金额，时间字段统一交给数据库，两边各管各的。

事务回滚也是这段代码的重点：如果第 5 步更新房间失败，前面插入的账单和入住单状态会一起回滚，不会出现「账单建了但房间还显示在住」的脏数据。大作业演示时，可以故意在退房前把房间表加一个触发器来制造失败，然后展示数据没有被破坏，这一手在答辩现场相当加分。

4.3 统计报表：房间利用率与月度营收的聚合查询

报表模块是「锦上添花」也是「必背考点」。很多大作业的报表只是把SELECT * FROM bill列一遍，没有聚合。实际上导师更愿意看到的是按月的营收、按房型的入住间夜数、房间利用率这类统计，这类查询用一条 GROUP BY 就能完成。

-- 按月份统计营收与间夜数 SELECT DATE_FORMAT(checkin_time, '%Y-%m') AS month, COUNT(DISTINCT checkin_id) AS orders, SUM(days) AS room_nights, SUM(total) AS revenue FROM bill GROUP BY month ORDER BY month DESC;

DATE_FORMAT把时间戳归并到月份，COUNT(DISTINCT checkin_id)统计单数，SUM(days)是间夜数，SUM(total)是实收金额。这张表的演示价值在于：前台的每一笔退房都会实时反映到这里，验收时先退一间房，再刷新报表看到数字变化，账目对得上的过程本身就是最好的演示。

房间利用率需要拿到房间总数做分母，可以用一条子查询：

SELECT room_type, COUNT(*) AS total_rooms, SUM(IF(status = 2, 1, 0)) AS occupied_rooms, ROUND(SUM(IF(status = 2, 1, 0)) / COUNT(*) * 100, 1) AS usage_rate FROM room GROUP BY room_type;

这里用IF(status = 2, 1, 0)把在住状态转成 0/1 再求和，就得到了在住房间数。注意usage_rate是瞬时值，只反映查询那一刻的占用率，文档里要把这个口径写清楚，别让导师误以为这是月度平均利用率。真正算月度利用率要用间夜数除以（房间数×当月天数），数据量小的时候直接展示瞬时利用率完全够用。

5. 数据库大作业避坑指南：乱码、外键与事务的五个现场

这一章写的是我在类似项目里反复踩过的坑。每一条都按「现象 → 原因 → 解决」来写，你在本地复现时大概率会撞上其中几条。提前排掉，演示时才不会当场翻车。

5.1 中文乱码：连接串、建库编码与终端三方对齐

现象：向 customer 表插入「张伟」后，表里存的是???或å¼ ä¼，控制台输出乱码。

原因：建库时用了默认 latin1 字符集，或者config.py里的charset没写，导致连接层用 latin1 与 utf8mb4 的库交换数据。还有一种是数据本身没问题，但 Windows 控制台的代码页不是 UTF-8，查询结果显示乱码，造成「数据坏了」的假象。

解决：三处统一。第一处建库建表全部指定DEFAULT CHARSET utf8mb4；第二处连接参数写charset='utf8mb4'；第三处是终端编码，Windows 上在运行程序前执行chcp 65001或把脚本输出重定向的编码改为 UTF-8。验证方法是插入一条中文后，在可视化客户端里直接看表数据，如果客户端显示正常而控制台乱码，那问题只在终端，不在数据。这个区分能帮你节省大量排查时间。

5.2 外键约束失败：删除顺序与级联策略

现象：执行DELETE FROM room WHERE room_id = 1时，MySQL 报外键约束失败，提示 reservation 表里有记录还在引用这个房间。很多同学遇到这个报错的第一反应是删外键，其实方向反了。

原因：代码里建立外键后，子表存在关联记录时，父表不能直接删。这是数据库保证引用完整性的正常行为，不是配置错误。

解决：按业务顺序先删子表记录或先完成退房释放关联，再删父表。大作业的房态管理里，房间一般不物理删除，而是把status改成 3（维修）或 4（停用），这样既保留历史账单的可追溯性，又避免外键问题。如果你确实要做物理删除，可以在建表时给外键加ON DELETE CASCADE，但账单这类结算数据不建议级联删除，删了账就没了。我一般会在文档里写清楚：历史数据用状态标记，不物理删除，这个设计能挡住答辩时的连环追问。

5.3 日期字段的时区与格式陷阱

现象：退房的天数有时比实际少一天或错一天。比如 1 号 23:00 入住、3 号 00:30 退房，算出来是 2 天，而业务上应该是 3 天。

原因：datetime.now()返回的本地时间与数据库NOW()之间的时区不一致，或者 Python 侧把 DATETIME 转成了 date 类型再做减法，导致边界时刻被截断。

解决：统一口径。入住与退房的时间字段全部存 DATETIME，计算天数时不要把时间转成 date 再减，而是直接用datetime.now() - checkin_time算天数再向上取整。边界情况用days = (now - checkin).days + 1，保证当天入住即使不满 24 小时也算一天。另一个常见坑是datetime.now()与数据库的CURRENT_TIMESTAMP有时区差，请在连接参数里显式指定time_zone='+08:00'或直接在config.py里写入，不要依赖 MySQL 服务器默认时区。这两个做法能让退房账单经得起现场对账。

5.4 事务没提交：数据「消失」与自增主键跳号的真相

现象：程序运行正常，插入客户后界面也显示成功，但重启程序或重启 MySQL 后，刚才的数据不见了。更诡异的是自增主键已经跳到 8，但表里只有 3 行。

原因：pymysql 的autocommit=False时，cursor.execute执行成功只代表语句执行成功，事务还没提交。程序异常退出时连接被 MySQL 回收，未提交的事务自动回滚，数据看起来就「消失」了。自增主键跳号是因为 MySQL 的自增值在回滚后不会回退，这是正常行为。

解决：所有写操作必须走统一提交入口，也就是第 3 章的execute方法，里面commit()之后才算真正落库。开启自动提交（autocommit=True）也可以，但多步事务场景下容易把中间状态也提交出去，所以我更推荐保持手动提交，只在事务收尾处 commit。排查时用SELECT * FROM bill直接看表，对比界面实时数据和表数据，就能确认是不是没提交。

5.5 文档与代码脱节：ER 图、数据字典要跟着改

现象：文档里的数据字典写着 room 表的status是 VARCHAR(10)，代码里却是 TINYINT；ER 图里没有 bill 表，代码里却一直在 insert bill。答辩时导师逐页翻文档，现场对不上，整个系统可信度直接打折。

原因：写文档和写代码不是同一天完成的，中途改了表结构只改了 SQL 脚本，忘了同步文档。这是大作业最常见的「非技术扣分点」。

解决：把文档更新放进开发流程而不是收尾流程。我的习惯是每次建表或改表，顺手把第 2.3 节的数据字典表格同步一次；全部功能做完后，从数据库反向导出一份表结构，和文档对照检查。具体可以执行SHOW CREATE TABLE room;查看实际结构，再与文档表格逐字段核对。如果想让这一步自动化，可以在sql/init.sql里给每个字段写清 COMMENT，然后写一个提取字段清单的小脚本，人工确认差异。文档和代码对齐这件事，不靠记忆，靠流程。

6. 演示验收与加餐设计：把 80 分的系统讲出 90 分的效果

代码和文档都齐了，最后一步是让系统在验收现场稳定呈现。我的习惯是准备一个初始化脚本和一张验收清单，把演示从头到尾排一遍，不给现场留意外。

6.1 一键初始化演示数据脚本

手动在界面点十几次去造数据，浪费时间且容易漏步骤。写一个init_demo_data.py，连接数据库后清空业务表、插入若干房间、客户和一笔已完成的历史账单，让报表模块一开始就有数据可看。

# init_demo_data.py from db import Database from config import config db = Database(config) with db.conn.cursor() as cursor: cursor.execute("SET FOREIGN_KEY_CHECKS = 0") for table in ('bill', 'checkin', 'reservation', 'customer', 'room'): cursor.execute(f"TRUNCATE TABLE {table}") cursor.execute("SET FOREIGN_KEY_CHECKS = 1") cursor.execute(""" INSERT INTO room (room_no, room_type, price, floor, status) VALUES ('201', '标准间', 238.00, 2, 0), ('202', '标准间', 238.00, 2, 0), ('301', '套房', 588.00, 3, 0) """) cursor.execute(""" INSERT INTO customer (name, id_card, phone) VALUES ('演示客户', '123456199001011234', '13800000000') """) db.conn.commit() db.close()

TRUNCATE TABLE之前关掉外键检查，是因为清表顺序遵循「先子后父」时通常不会报错，但遇到自增 ID 关联复杂时直接临时关闭更省心。注意TRUNCATE会重置自增主键，演示数据要从固定 ID 开始，保证步骤可重复。

6.2 验收演示清单与追问应答

演示前把流程写成清单，每完成一步就核对一个检查点：

这张清单本身就是答辩的「演示脚本」。导师追问「并发怎么办」时，答FOR UPDATE与事务回滚；问「状态流失效怎么办」时，答预订状态的自动释放逻辑。追问的答案都在第 4 章的代码里，不要临时翻代码，把这些关键句背下来。我第一次做类似题目时，栽在最不起眼的细节上：演示前没有重置数据库，前一天测试的数据还残留在表里，导致房态混乱被当场质疑。后来的习惯是每次演示前先跑一遍初始化脚本，把「现场翻车」变成「剧本式演示」。大作业拼的不是炫技，而是每一步都经得起追问。希望帮到你。

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