简介一份面向数据库课程设计、毕业设计及期末大作业场景的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-维修 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; 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 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这段 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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; 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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; 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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;说明一下两个设计细节。checkin.reservation_id允许为空是因为业务上存在「客人直接到店办理入住」的场景没有预订也要能开单如果把这个字段设为 NOT NULL反而会把业务流程写死。bill冗余了room_id和customer_id这在第三范式上属于冗余但大作业阶段的账单表通常要支持独立查询比如「某个客户今年消费了多少」冗余两个字段能少做两次联表查询代价是更新时必须保证一致实际项目中这类冗余需要和导师提前说明理由。2.3 数据字典文档文档说明里最值钱的一页文档说明是标题交付物的一部分很多同学把文档写成「软件使用说明书」教人点按钮这不是数据库大作业要的东西。文档里最值钱的是数据字典也就是每张表的字段级说明。导师翻文档时重点看三样表之间关系是否讲清、字段类型和注释是否与建表脚本一致、有没有说明状态字段的取值含义。数据字典用表格写最直观以 room 表为例字段名类型允许空键说明room_idINT否主键房间编号自增room_noVARCHAR(10)否唯一房间号如 301room_typeVARCHAR(20)否无单人间/标准间/套房priceDECIMAL(10,2)否无挂牌价单位元floorTINYINT否无楼层statusTINYINT否无0-空闲 1-已预订 2-已入住 3-维修每张表配一个这样的表格再把外键关系单独画一页说明文档的数据库部分就算扎实了。状态字段的取值含义不要只写在表注释里要在文档正文单独列一段「状态约定」包括预订表的 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( hostself.config[host], portself.config[port], userself.config[user], passwordself.config[password], databaseself.config[database], charsetutf8mb4, cursorclassDictCursor, autocommitFalse, # 关闭自动提交写操作显式 commit ) return conn def query_all(self, sql, argsNone): 查询多条记录返回 list[dict] with self.conn.cursor() as cursor: cursor.execute(sql, args) return cursor.fetchall() def query_one(self, sql, argsNone): 查询单条记录没有则返回 None with self.conn.cursor() as cursor: cursor.execute(sql, args) return cursor.fetchone() def execute(self, sql, argsNone): 执行写操作成功后立即提交返回受影响行数 with self.conn.cursor() as cursor: rows cursor.execute(sql, args) self.conn.commit() return rows def close(self): self.conn.close()说明几个参数。cursorclassDictCursor让查询结果变成字典列表代码里写row[name]而不是row[1]可读性好很多也避免表结构调整后按下标取值取错。autocommitFalse是刻意为之配合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_rate1.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第二处连接参数写charsetutf8mb4第三处是终端编码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_zone08:00或直接在config.py里写入不要依赖 MySQL 服务器默认时区。这两个做法能让退房账单经得起现场对账。5.4 事务没提交数据「消失」与自增主键跳号的真相现象程序运行正常插入客户后界面也显示成功但重启程序或重启 MySQL 后刚才的数据不见了。更诡异的是自增主键已经跳到 8但表里只有 3 行。原因pymysql 的autocommitFalse时cursor.execute执行成功只代表语句执行成功事务还没提交。程序异常退出时连接被 MySQL 回收未提交的事务自动回滚数据看起来就「消失」了。自增主键跳号是因为 MySQL 的自增值在回滚后不会回退这是正常行为。解决所有写操作必须走统一提交入口也就是第 3 章的execute方法里面commit()之后才算真正落库。开启自动提交autocommitTrue也可以但多步事务场景下容易把中间状态也提交出去所以我更推荐保持手动提交只在事务收尾处 commit。排查时用SELECT * FROM bill直接看表对比界面实时数据和表数据就能确认是不是没提交。5.5 文档与代码脱节ER 图、数据字典要跟着改现象文档里的数据字典写着 room 表的status是 VARCHAR(10)代码里却是 TINYINTER 图里没有 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(fTRUNCATE 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 验收演示清单与追问应答演示前把流程写成清单每完成一步就核对一个检查点序号演示步骤检查点1运行初始化脚本三张房间表、一名客户就绪2查询空闲房间按房型筛选出 201、3013为客户预订 201 两天房间状态变为已预订4重复预订同日期 201页面提示冲突5办理入住201 状态变为已入住生成入住单6退房结算账单金额 238 × 2房态释放为空闲7查看月报营收与刚才的账单一致这张清单本身就是答辩的「演示脚本」。导师追问「并发怎么办」时答FOR UPDATE与事务回滚问「状态流失效怎么办」时答预订状态的自动释放逻辑。追问的答案都在第 4 章的代码里不要临时翻代码把这些关键句背下来。我第一次做类似题目时栽在最不起眼的细节上演示前没有重置数据库前一天测试的数据还残留在表里导致房态混乱被当场质疑。后来的习惯是每次演示前先跑一遍初始化脚本把「现场翻车」变成「剧本式演示」。大作业拼的不是炫技而是每一步都经得起追问。希望帮到你。本文还有配套的精品资源点击获取
