简介这份数据库课程设计文档面向高校计算机相关专业学生围绕「某电力公司收费管理信息系统」这一典型课题提供从需求分析到数据库落地的完整设计思路。内容涵盖客户、用电类型、员工、用电信息、费用管理、收费登记等六张核心表的关系模型与E-R图并给出建表语句与示例数据便于理解一对多关联与主外键约束。文档还涉及视图、触发器、存储过程的实现要点如收费时自动更新应收与实收费用、按月份统计未交费用户等并配有数据流程图、程序流程图与功能模块图帮助读者掌握Oracle与C#.NET结合的开发流程。资源包为1个doc文件约261KB结构紧凑适合作为课程设计参考模板或答辩材料。目前已有241人学习可辅助快速梳理设计报告框架与实现细节。1. 电力公司收费系统数据库课设里最容易被低估的硬骨头很多同学拿到“数据库课程设计电力公司收费系统”这个题目第一反应是“不就是几张表加增删改查”。真动手才发现电费不是简单的单价乘电量居民阶梯电价、工商业分时电价、变压器损耗分摊、违约金计算、预存余额抵扣每一条都能让表结构推倒重来。我带过几届课设翻车最多的不是写不出 SQL而是需求没拆干净就急着建表最后电费算不平只能靠硬编码补丁续命。这个系统的本质是把“抄表—计费—收费—欠费追缴”这条业务链用关系模型固化下来再用事务保证钱和账一致。它适合数据库课设因为业务规则足够复杂能逼你练范式设计、事务、触发器、视图和存储过程也适合作为求职作品因为电费结算逻辑贴近真实计费系统。下面按我实际带课设的路径从需求拆解一路讲到对账技巧。2. 需求拆解与表结构设计先画业务流再落关系模型2.1 把收费业务拆成四张核心表电力收费的业务主线其实只有四步用户档案建立、抄表数据录入、电费计算、收款与欠费处理。围绕这条线最小可用模型需要四张核心表用户表、电表表、抄表记录表、电费账单表再加一张收款流水表。很多人一上来就建十几张表结果字段冗余、外键混乱查询时自己都绕晕。我一般建议先画一张业务流草图纸笔即可标出每一步产生什么数据、由谁写入、被谁读取。比如抄表记录由抄表员写入被计费程序读取账单由计费程序生成被收费窗口读取并更新状态。把“谁写谁读”标清楚表之间的外键方向自然就出来了。下面是我常用的建表脚本以 MySQL 8.0 为例字段类型和约束都按课设可落地标准来-- 用户表保存用电客户基本信息 CREATE TABLE t_user ( user_id BIGINT PRIMARY KEY AUTO_INCREMENT, user_no VARCHAR(20) NOT NULL UNIQUE COMMENT 用户编号对外唯一, user_name VARCHAR(50) NOT NULL, user_type TINYINT NOT NULL DEFAULT 1 COMMENT 1居民 2工商业 3农业, address VARCHAR(200), phone VARCHAR(20), balance DECIMAL(12,2) NOT NULL DEFAULT 0.00 COMMENT 预存余额, status TINYINT NOT NULL DEFAULT 1 COMMENT 1正常 0销户, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 电表表一个用户可能有多块表总表/分表 CREATE TABLE t_meter ( meter_id BIGINT PRIMARY KEY AUTO_INCREMENT, meter_no VARCHAR(30) NOT NULL UNIQUE, user_id BIGINT NOT NULL, meter_type TINYINT NOT NULL DEFAULT 1 COMMENT 1单相 2三相, install_date DATE, status TINYINT NOT NULL DEFAULT 1, CONSTRAINT fk_meter_user FOREIGN KEY (user_id) REFERENCES t_user(user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 抄表记录表每次抄表一条记录起止读数 CREATE TABLE t_meter_reading ( reading_id BIGINT PRIMARY KEY AUTO_INCREMENT, meter_id BIGINT NOT NULL, read_date DATE NOT NULL, prev_reading DECIMAL(12,2) NOT NULL COMMENT 上次读数, curr_reading DECIMAL(12,2) NOT NULL COMMENT 本次读数, usage_kwh DECIMAL(12,2) GENERATED ALWAYS AS (curr_reading - prev_reading) STORED COMMENT 用电量, reader_id BIGINT, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, CONSTRAINT fk_reading_meter FOREIGN KEY (meter_id) REFERENCES t_meter(meter_id), UNIQUE KEY uk_meter_date (meter_id, read_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 电费账单表每月每表一条账单 CREATE TABLE t_bill ( bill_id BIGINT PRIMARY KEY AUTO_INCREMENT, bill_no VARCHAR(32) NOT NULL UNIQUE, user_id BIGINT NOT NULL, meter_id BIGINT NOT NULL, bill_month CHAR(7) NOT NULL COMMENT 账期格式2025-06, usage_kwh DECIMAL(12,2) NOT NULL, amount DECIMAL(12,2) NOT NULL COMMENT 应收电费, penalty DECIMAL(12,2) NOT NULL DEFAULT 0.00 COMMENT 违约金, paid_amount DECIMAL(12,2) NOT NULL DEFAULT 0.00 COMMENT 已收金额, status TINYINT NOT NULL DEFAULT 0 COMMENT 0未缴 1部分缴 2已缴清, due_date DATE NOT NULL COMMENT 缴费截止日, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, CONSTRAINT fk_bill_user FOREIGN KEY (user_id) REFERENCES t_user(user_id), CONSTRAINT fk_bill_meter FOREIGN KEY (meter_id) REFERENCES t_meter(meter_id), UNIQUE KEY uk_meter_month (meter_id, bill_month) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 收款流水表每笔收款一条不修改不删除 CREATE TABLE t_payment ( payment_id BIGINT PRIMARY KEY AUTO_INCREMENT, bill_id BIGINT NOT NULL, pay_amount DECIMAL(12,2) NOT NULL, pay_method TINYINT NOT NULL DEFAULT 1 COMMENT 1现金 2刷卡 3线上, pay_time DATETIME DEFAULT CURRENT_TIMESTAMP, operator_id BIGINT, CONSTRAINT fk_payment_bill FOREIGN KEY (bill_id) REFERENCES t_bill(bill_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这段脚本有几个设计取舍值得说清楚。第一usage_kwh用生成列而不是普通字段保证用电量永远等于本次减上次避免应用层算错或被人为改数。第二账单表里同时存amount和paid_amount而不是只存一个状态因为部分缴费是真实场景只靠状态字段无法表达“还差多少”。第三收款流水表只增不改这是对账的后悔药——任何一笔钱都能追溯到原始记录。参数上金额统一用DECIMAL(12,2)不要用FLOAT浮点误差在电费场景是致命的。用户编号、表号、账单号都加唯一约束防止重复录入。外键统一用InnoDB课设阶段不必考虑分库分表。2.2 阶梯电价与分时电价的表结构表达电价规则是这个系统最容易翻车的地方。居民阶梯电价按年用电量分档工商业分时电价按峰平谷时段计价。如果把电价写死在代码里改一次规则就要改代码正确做法是把电价规则也做成表。我一般会加两张规则表电价方案表和阶梯明细表。电价方案表记录方案名称、适用用户类型、生效日期阶梯明细表记录每个方案下的档位、上下限、单价。分时电价则再加一张时段表记录峰平谷的起止时间和对应单价。-- 电价方案表 CREATE TABLE t_price_plan ( plan_id BIGINT PRIMARY KEY AUTO_INCREMENT, plan_name VARCHAR(50) NOT NULL, user_type TINYINT NOT NULL COMMENT 适用用户类型, effective_date DATE NOT NULL, status TINYINT NOT NULL DEFAULT 1 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 阶梯明细表居民阶梯电价用 CREATE TABLE t_price_tier ( tier_id BIGINT PRIMARY KEY AUTO_INCREMENT, plan_id BIGINT NOT NULL, tier_no INT NOT NULL COMMENT 第几档, lower_kwh DECIMAL(12,2) NOT NULL COMMENT 本档起始电量, upper_kwh DECIMAL(12,2) COMMENT 本档结束电量NULL表示无上限, unit_price DECIMAL(8,4) NOT NULL COMMENT 单价元/度, CONSTRAINT fk_tier_plan FOREIGN KEY (plan_id) REFERENCES t_price_plan(plan_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 分时时段表工商业分时电价用 CREATE TABLE t_price_period ( period_id BIGINT PRIMARY KEY AUTO_INCREMENT, plan_id BIGINT NOT NULL, period_type TINYINT NOT NULL COMMENT 1峰 2平 3谷, start_time TIME NOT NULL, end_time TIME NOT NULL, unit_price DECIMAL(8,4) NOT NULL, CONSTRAINT fk_period_plan FOREIGN KEY (plan_id) REFERENCES t_price_plan(plan_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;把电价规则表化之后计费程序只负责“按规则查表计算”规则变更只改数据不改代码。这是课设里能体现设计水平的关键点也是答辩时容易被追问的地方。注意阶梯明细表的upper_kwh允许为 NULL表示最高档无上限查询时用COALESCE或IS NULL处理。2.3 用视图把“账单用户表号”拼成收费窗口要看的界面收费窗口的人不关心表结构他们只想看到“某用户某月欠多少钱”。这种跨表拼接用视图最合适既避免在应用层写重复 JOIN也让权限控制更简单——收费员只给视图查询权限不给基表权限。CREATE VIEW v_bill_detail AS SELECT b.bill_id, b.bill_no, u.user_no, u.user_name, u.phone, m.meter_no, b.bill_month, b.usage_kwh, b.amount, b.penalty, b.paid_amount, (b.amount b.penalty - b.paid_amount) AS owe_amount, b.status, b.due_date FROM t_bill b JOIN t_user u ON b.user_id u.user_id JOIN t_meter m ON b.meter_id m.meter_id;视图里直接算出owe_amount应用层不用再算。注意视图不存储数据每次查询都实时计算所以基表数据变了视图立刻反映。课设阶段数据量小性能不是问题如果数据量大再考虑物化视图或定时汇总表。3. 计费与收款的事务实现钱和账必须一起动3.1 阶梯电费计算的存储过程计费逻辑我建议放在存储过程里原因是它离数据最近能在一个事务里完成“读抄表记录—算电费—写账单”避免应用层多次往返导致中间状态不一致。下面是一个居民阶梯电费的简化版存储过程DELIMITER $$ CREATE PROCEDURE sp_calc_bill( IN p_meter_id BIGINT, IN p_bill_month CHAR(7), IN p_plan_id BIGINT ) BEGIN DECLARE v_usage DECIMAL(12,2); DECLARE v_amount DECIMAL(12,2) DEFAULT 0.00; DECLARE v_prev DECIMAL(12,2) DEFAULT 0.00; DECLARE v_curr DECIMAL(12,2); DECLARE v_tier_no INT DEFAULT 1; DECLARE v_lower DECIMAL(12,2); DECLARE v_upper DECIMAL(12,2); DECLARE v_price DECIMAL(8,4); DECLARE v_done INT DEFAULT 0; DECLARE v_user_id BIGINT; DECLARE v_due DATE; -- 游标遍历阶梯档位 DECLARE cur_tier CURSOR FOR SELECT tier_no, lower_kwh, upper_kwh, unit_price FROM t_price_tier WHERE plan_id p_plan_id ORDER BY tier_no; DECLARE CONTINUE HANDLER FOR NOT FOUND SET v_done 1; -- 取本月用电量 SELECT usage_kwh INTO v_usage FROM t_meter_reading WHERE meter_id p_meter_id AND DATE_FORMAT(read_date, %Y-%m) p_bill_month; IF v_usage IS NULL THEN SIGNAL SQLSTATE 45000 SET MESSAGE_TEXT 该表本月无抄表记录; END IF; -- 取用户和截止日 SELECT user_id INTO v_user_id FROM t_meter WHERE meter_id p_meter_id; SET v_due LAST_DAY(CONCAT(p_bill_month, -01)); -- 按阶梯累加电费 SET v_prev 0; OPEN cur_tier; read_loop: LOOP FETCH cur_tier INTO v_tier_no, v_lower, v_upper, v_price; IF v_done 1 THEN LEAVE read_loop; END IF; IF v_usage v_lower THEN LEAVE read_loop; END IF; -- 本档计费电量 min(总用电, 本档上限) - 本档起始 SET v_curr LEAST(v_usage, COALESCE(v_upper, v_usage)) - v_lower; IF v_curr 0 THEN SET v_amount v_amount v_curr * v_price; END IF; END LOOP; CLOSE cur_tier; -- 写入账单唯一键冲突则更新 INSERT INTO t_bill (bill_no, user_id, meter_id, bill_month, usage_kwh, amount, due_date) VALUES (CONCAT(B, p_bill_month, p_meter_id), v_user_id, p_meter_id, p_bill_month, v_usage, v_amount, v_due) ON DUPLICATE KEY UPDATE usage_kwh v_usage, amount v_amount; END$$ DELIMITER ;这段逻辑的关键在阶梯累加每档只对落在该档区间内的电量计费LEAST(v_usage, COALESCE(v_upper, v_usage)) - v_lower是核心表达式。COALESCE(v_upper, v_usage)处理最高档无上限的情况。ON DUPLICATE KEY UPDATE保证重复计费不会产生两条账单靠的是账单表上(meter_id, bill_month)的唯一键。参数说明p_meter_id是电表主键p_bill_month格式必须是YYYY-MMp_plan_id指向电价方案。如果本月没有抄表记录存储过程直接抛错不会生成金额为 0 的假账单。这是血泪经验——早期版本没做这个校验结果空账单混进收费列表对账时多出一堆零元单。3.2 收款事务余额抵扣与流水写入必须原子收款环节最怕的是“钱扣了但账单没更新”或者“账单更新了但流水没记”。这两件事必须在同一个事务里完成。下面是一个收款存储过程支持预存余额抵扣和现金收款两种方式DELIMITER $$ CREATE PROCEDURE sp_pay_bill( IN p_bill_id BIGINT, IN p_pay_amount DECIMAL(12,2), IN p_pay_method TINYINT, IN p_operator_id BIGINT ) BEGIN DECLARE v_owe DECIMAL(12,2); DECLARE v_paid DECIMAL(12,2); DECLARE v_amount DECIMAL(12,2); DECLARE v_penalty DECIMAL(12,2); DECLARE v_user_id BIGINT; DECLARE v_balance DECIMAL(12,2); -- 开启事务 START TRANSACTION; -- 锁定账单行防止并发重复收款 SELECT amount, penalty, paid_amount, user_id INTO v_amount, v_penalty, v_paid, v_user_id FROM t_bill WHERE bill_id p_bill_id FOR UPDATE; SET v_owe v_amount v_penalty - v_paid; IF p_pay_amount 0 THEN SIGNAL SQLSTATE 45000 SET MESSAGE_TEXT 收款金额必须大于0; END IF; IF p_pay_amount v_owe THEN SIGNAL SQLSTATE 45000 SET MESSAGE_TEXT 收款金额超过欠费金额; END IF; -- 更新账单已收金额和状态 UPDATE t_bill SET paid_amount paid_amount p_pay_amount, status CASE WHEN paid_amount p_pay_amount amount penalty THEN 2 ELSE 1 END WHERE bill_id p_bill_id; -- 写入收款流水 INSERT INTO t_payment (bill_id, pay_amount, pay_method, operator_id) VALUES (p_bill_id, p_pay_amount, p_pay_method, p_operator_id); -- 如果是余额抵扣扣减用户余额 IF p_pay_method 4 THEN SELECT balance INTO v_balance FROM t_user WHERE user_id v_user_id FOR UPDATE; IF v_balance p_pay_amount THEN SIGNAL SQLSTATE 45000 SET MESSAGE_TEXT 预存余额不足; END IF; UPDATE t_user SET balance balance - p_pay_amount WHERE user_id v_user_id; END IF; COMMIT; END$$ DELIMITER ;这里有两个必须注意的点。第一SELECT ... FOR UPDATE锁住账单行防止两个收费窗口同时收同一笔账单导致重复抵扣。第二余额抵扣时也要锁用户行否则并发扣余额会扣成负数。事务边界从START TRANSACTION到COMMIT中间任何一步失败都回滚保证钱和账一致。参数上p_pay_method我扩展了 4 表示余额抵扣和前面的 1/2/3 区分开。实际课设里可以简化但建议保留这个分支因为它能体现你对“预存电费”场景的理解。3.3 违约金自动计算的触发器违约金按逾期天数计算常见规则是每日万分之五。用触发器在账单更新时自动算比定时任务简单课设阶段够用。DELIMITER $$ CREATE TRIGGER trg_bill_penalty BEFORE UPDATE ON t_bill FOR EACH ROW BEGIN -- 仅当账单未缴清且已过截止日时计算违约金 IF NEW.status 2 AND NEW.due_date CURDATE() THEN SET NEW.penalty ROUND(NEW.amount * 0.0005 * DATEDIFF(CURDATE(), NEW.due_date), 2); END IF; END$$ DELIMITER ;触发器逻辑简单但要注意它只在UPDATE时触发如果账单生成后一直没人动违约金不会自动更新。所以实际系统里通常配合一个每日定时任务批量刷新。课设里可以手动执行一条UPDATE t_bill SET status status WHERE ...来触发或者干脆在查询时用视图实时算。触发器适合演示“自动计算”这个概念但别把它当成唯一手段。4. 避坑与排查课设答辩前必须过的五道坎4.1 电费算不平差几分钱现象手工核算和系统算出的电费差 0.01 到 0.05 元。原因通常是浮点类型或四舍五入时机不对。解决金额字段全部用DECIMAL单价用DECIMAL(8,4)最终金额用ROUND(..., 2)统一保留两位。不要在中间步骤提前舍入累加完再舍入。4.2 抄表记录重复录入现象同一块表同一个月出现两条抄表记录计费时取到错误的一条。原因没加唯一约束。解决抄表记录表加UNIQUE KEY (meter_id, read_date)应用层插入时捕获唯一键冲突并提示“本月已抄表”。如果业务允许补抄改成(meter_id, read_date, read_seq)联合唯一。4.3 并发收款导致余额扣成负数现象两个收费员同时给同一用户做余额抵扣余额被扣两次。原因没加行锁。解决在事务里用SELECT ... FOR UPDATE锁住用户行和账单行扣减前再校验一次余额。注意锁的顺序要一致先锁账单再锁用户避免死锁。4.4 账单状态和已收金额不一致现象账单显示“已缴清”但paid_amount小于amount penalty。原因状态更新逻辑写错或者手工改过数据。解决状态不要手工维护用生成列或触发器根据paid_amount自动推导。查询时用CASE WHEN paid_amount amount penalty THEN 2 ...实时判断避免状态字段成为黑匣子。4.5 删除用户导致账单丢失现象删除一个销户用户后历史账单查不到了。原因外键没设ON DELETE RESTRICT或者用了级联删除。解决用户表加status字段做逻辑删除物理删除一律禁止。外键统一用RESTRICT账单和流水是财务数据任何情况下不能跟着用户一起消失。5. 对账与数据校验让系统自己证明自己没算错课设答辩时老师最常问的一句话是“你怎么证明你的电费算对了”。与其口头解释不如写几条对账 SQL让系统自己证明。我一般会准备三组校验查询答辩前跑一遍结果全为 0 才放心。第一组账单金额与流水汇总是否一致。-- 检查每张账单的已收金额是否等于流水汇总 SELECT b.bill_id, b.paid_amount, COALESCE(SUM(p.pay_amount), 0) AS flow_sum FROM t_bill b LEFT JOIN t_payment p ON b.bill_id p.bill_id GROUP BY b.bill_id, b.paid_amount HAVING b.paid_amount COALESCE(SUM(p.pay_amount), 0);这条查询返回空集说明账单上的已收金额和流水记录完全对得上。如果有差异要么是收款时事务没包住要么是有人手工改了账单。第二组用电量是否等于抄表差值。-- 检查账单用电量与抄表记录是否一致 SELECT b.bill_id, b.usage_kwh, r.usage_kwh AS reading_usage FROM t_bill b JOIN t_meter_reading r ON b.meter_id r.meter_id AND DATE_FORMAT(r.read_date, %Y-%m) b.bill_month WHERE b.usage_kwh r.usage_kwh;因为usage_kwh在抄表记录里是生成列这条查询理论上永远为空。如果非空说明账单写入时用了错误的数据源。第三组阶梯电价分档累加是否覆盖全部电量。-- 检查每个阶梯方案的分档是否连续无缺口 SELECT plan_id, tier_no, lower_kwh, upper_kwh, LAG(upper_kwh) OVER (PARTITION BY plan_id ORDER BY tier_no) AS prev_upper FROM t_price_tier ORDER BY plan_id, tier_no;人工看prev_upper是否等于当前行的lower_kwh如果有缺口说明阶梯配置有断档计费时会漏算电量。这个检查在新增电价方案后必做。除了这三组我还会在账单表上建一个汇总视图按账期统计应收、实收、欠费总额和收费窗口的日报表核对。对账这件事宁可多写几条 SQL也别等到答辩时被问住。我自己的习惯是每次改完计费逻辑先跑对账查询全绿了再继续写前端。这个习惯帮我省掉了至少三次返工。希望帮到你。本文还有配套的精品资源点击获取
简介这份数据库课程设计文档面向高校计算机相关专业学生围绕「某电力公司收费管理信息系统」这一典型课题提供从需求分析到数据库落地的完整设计思路。内容涵盖客户、用电类型、员工、用电信息、费用管理、收费登记等六张核心表的关系模型与E-R图并给出建表语句与示例数据便于理解一对多关联与主外键约束。文档还涉及视图、触发器、存储过程的实现要点如收费时自动更新应收与实收费用、按月份统计未交费用户等并配有数据流程图、程序流程图与功能模块图帮助读者掌握Oracle与C#.NET结合的开发流程。资源包为1个doc文件约261KB结构紧凑适合作为课程设计参考模板或答辩材料。目前已有241人学习可辅助快速梳理设计报告框架与实现细节。1. 电力公司收费系统数据库课设里最容易被低估的硬骨头很多同学拿到“数据库课程设计电力公司收费系统”这个题目第一反应是“不就是几张表加增删改查”。真动手才发现电费不是简单的单价乘电量居民阶梯电价、工商业分时电价、变压器损耗分摊、违约金计算、预存余额抵扣每一条都能让表结构推倒重来。我带过几届课设翻车最多的不是写不出 SQL而是需求没拆干净就急着建表最后电费算不平只能靠硬编码补丁续命。这个系统的本质是把“抄表—计费—收费—欠费追缴”这条业务链用关系模型固化下来再用事务保证钱和账一致。它适合数据库课设因为业务规则足够复杂能逼你练范式设计、事务、触发器、视图和存储过程也适合作为求职作品因为电费结算逻辑贴近真实计费系统。下面按我实际带课设的路径从需求拆解一路讲到对账技巧。2. 需求拆解与表结构设计先画业务流再落关系模型2.1 把收费业务拆成四张核心表电力收费的业务主线其实只有四步用户档案建立、抄表数据录入、电费计算、收款与欠费处理。围绕这条线最小可用模型需要四张核心表用户表、电表表、抄表记录表、电费账单表再加一张收款流水表。很多人一上来就建十几张表结果字段冗余、外键混乱查询时自己都绕晕。我一般建议先画一张业务流草图纸笔即可标出每一步产生什么数据、由谁写入、被谁读取。比如抄表记录由抄表员写入被计费程序读取账单由计费程序生成被收费窗口读取并更新状态。把“谁写谁读”标清楚表之间的外键方向自然就出来了。下面是我常用的建表脚本以 MySQL 8.0 为例字段类型和约束都按课设可落地标准来-- 用户表保存用电客户基本信息 CREATE TABLE t_user ( user_id BIGINT PRIMARY KEY AUTO_INCREMENT, user_no VARCHAR(20) NOT NULL UNIQUE COMMENT 用户编号对外唯一, user_name VARCHAR(50) NOT NULL, user_type TINYINT NOT NULL DEFAULT 1 COMMENT 1居民 2工商业 3农业, address VARCHAR(200), phone VARCHAR(20), balance DECIMAL(12,2) NOT NULL DEFAULT 0.00 COMMENT 预存余额, status TINYINT NOT NULL DEFAULT 1 COMMENT 1正常 0销户, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 电表表一个用户可能有多块表总表/分表 CREATE TABLE t_meter ( meter_id BIGINT PRIMARY KEY AUTO_INCREMENT, meter_no VARCHAR(30) NOT NULL UNIQUE, user_id BIGINT NOT NULL, meter_type TINYINT NOT NULL DEFAULT 1 COMMENT 1单相 2三相, install_date DATE, status TINYINT NOT NULL DEFAULT 1, CONSTRAINT fk_meter_user FOREIGN KEY (user_id) REFERENCES t_user(user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 抄表记录表每次抄表一条记录起止读数 CREATE TABLE t_meter_reading ( reading_id BIGINT PRIMARY KEY AUTO_INCREMENT, meter_id BIGINT NOT NULL, read_date DATE NOT NULL, prev_reading DECIMAL(12,2) NOT NULL COMMENT 上次读数, curr_reading DECIMAL(12,2) NOT NULL COMMENT 本次读数, usage_kwh DECIMAL(12,2) GENERATED ALWAYS AS (curr_reading - prev_reading) STORED COMMENT 用电量, reader_id BIGINT, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, CONSTRAINT fk_reading_meter FOREIGN KEY (meter_id) REFERENCES t_meter(meter_id), UNIQUE KEY uk_meter_date (meter_id, read_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 电费账单表每月每表一条账单 CREATE TABLE t_bill ( bill_id BIGINT PRIMARY KEY AUTO_INCREMENT, bill_no VARCHAR(32) NOT NULL UNIQUE, user_id BIGINT NOT NULL, meter_id BIGINT NOT NULL, bill_month CHAR(7) NOT NULL COMMENT 账期格式2025-06, usage_kwh DECIMAL(12,2) NOT NULL, amount DECIMAL(12,2) NOT NULL COMMENT 应收电费, penalty DECIMAL(12,2) NOT NULL DEFAULT 0.00 COMMENT 违约金, paid_amount DECIMAL(12,2) NOT NULL DEFAULT 0.00 COMMENT 已收金额, status TINYINT NOT NULL DEFAULT 0 COMMENT 0未缴 1部分缴 2已缴清, due_date DATE NOT NULL COMMENT 缴费截止日, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, CONSTRAINT fk_bill_user FOREIGN KEY (user_id) REFERENCES t_user(user_id), CONSTRAINT fk_bill_meter FOREIGN KEY (meter_id) REFERENCES t_meter(meter_id), UNIQUE KEY uk_meter_month (meter_id, bill_month) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 收款流水表每笔收款一条不修改不删除 CREATE TABLE t_payment ( payment_id BIGINT PRIMARY KEY AUTO_INCREMENT, bill_id BIGINT NOT NULL, pay_amount DECIMAL(12,2) NOT NULL, pay_method TINYINT NOT NULL DEFAULT 1 COMMENT 1现金 2刷卡 3线上, pay_time DATETIME DEFAULT CURRENT_TIMESTAMP, operator_id BIGINT, CONSTRAINT fk_payment_bill FOREIGN KEY (bill_id) REFERENCES t_bill(bill_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这段脚本有几个设计取舍值得说清楚。第一usage_kwh用生成列而不是普通字段保证用电量永远等于本次减上次避免应用层算错或被人为改数。第二账单表里同时存amount和paid_amount而不是只存一个状态因为部分缴费是真实场景只靠状态字段无法表达“还差多少”。第三收款流水表只增不改这是对账的后悔药——任何一笔钱都能追溯到原始记录。参数上金额统一用DECIMAL(12,2)不要用FLOAT浮点误差在电费场景是致命的。用户编号、表号、账单号都加唯一约束防止重复录入。外键统一用InnoDB课设阶段不必考虑分库分表。2.2 阶梯电价与分时电价的表结构表达电价规则是这个系统最容易翻车的地方。居民阶梯电价按年用电量分档工商业分时电价按峰平谷时段计价。如果把电价写死在代码里改一次规则就要改代码正确做法是把电价规则也做成表。我一般会加两张规则表电价方案表和阶梯明细表。电价方案表记录方案名称、适用用户类型、生效日期阶梯明细表记录每个方案下的档位、上下限、单价。分时电价则再加一张时段表记录峰平谷的起止时间和对应单价。-- 电价方案表 CREATE TABLE t_price_plan ( plan_id BIGINT PRIMARY KEY AUTO_INCREMENT, plan_name VARCHAR(50) NOT NULL, user_type TINYINT NOT NULL COMMENT 适用用户类型, effective_date DATE NOT NULL, status TINYINT NOT NULL DEFAULT 1 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 阶梯明细表居民阶梯电价用 CREATE TABLE t_price_tier ( tier_id BIGINT PRIMARY KEY AUTO_INCREMENT, plan_id BIGINT NOT NULL, tier_no INT NOT NULL COMMENT 第几档, lower_kwh DECIMAL(12,2) NOT NULL COMMENT 本档起始电量, upper_kwh DECIMAL(12,2) COMMENT 本档结束电量NULL表示无上限, unit_price DECIMAL(8,4) NOT NULL COMMENT 单价元/度, CONSTRAINT fk_tier_plan FOREIGN KEY (plan_id) REFERENCES t_price_plan(plan_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 分时时段表工商业分时电价用 CREATE TABLE t_price_period ( period_id BIGINT PRIMARY KEY AUTO_INCREMENT, plan_id BIGINT NOT NULL, period_type TINYINT NOT NULL COMMENT 1峰 2平 3谷, start_time TIME NOT NULL, end_time TIME NOT NULL, unit_price DECIMAL(8,4) NOT NULL, CONSTRAINT fk_period_plan FOREIGN KEY (plan_id) REFERENCES t_price_plan(plan_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;把电价规则表化之后计费程序只负责“按规则查表计算”规则变更只改数据不改代码。这是课设里能体现设计水平的关键点也是答辩时容易被追问的地方。注意阶梯明细表的upper_kwh允许为 NULL表示最高档无上限查询时用COALESCE或IS NULL处理。2.3 用视图把“账单用户表号”拼成收费窗口要看的界面收费窗口的人不关心表结构他们只想看到“某用户某月欠多少钱”。这种跨表拼接用视图最合适既避免在应用层写重复 JOIN也让权限控制更简单——收费员只给视图查询权限不给基表权限。CREATE VIEW v_bill_detail AS SELECT b.bill_id, b.bill_no, u.user_no, u.user_name, u.phone, m.meter_no, b.bill_month, b.usage_kwh, b.amount, b.penalty, b.paid_amount, (b.amount b.penalty - b.paid_amount) AS owe_amount, b.status, b.due_date FROM t_bill b JOIN t_user u ON b.user_id u.user_id JOIN t_meter m ON b.meter_id m.meter_id;视图里直接算出owe_amount应用层不用再算。注意视图不存储数据每次查询都实时计算所以基表数据变了视图立刻反映。课设阶段数据量小性能不是问题如果数据量大再考虑物化视图或定时汇总表。3. 计费与收款的事务实现钱和账必须一起动3.1 阶梯电费计算的存储过程计费逻辑我建议放在存储过程里原因是它离数据最近能在一个事务里完成“读抄表记录—算电费—写账单”避免应用层多次往返导致中间状态不一致。下面是一个居民阶梯电费的简化版存储过程DELIMITER $$ CREATE PROCEDURE sp_calc_bill( IN p_meter_id BIGINT, IN p_bill_month CHAR(7), IN p_plan_id BIGINT ) BEGIN DECLARE v_usage DECIMAL(12,2); DECLARE v_amount DECIMAL(12,2) DEFAULT 0.00; DECLARE v_prev DECIMAL(12,2) DEFAULT 0.00; DECLARE v_curr DECIMAL(12,2); DECLARE v_tier_no INT DEFAULT 1; DECLARE v_lower DECIMAL(12,2); DECLARE v_upper DECIMAL(12,2); DECLARE v_price DECIMAL(8,4); DECLARE v_done INT DEFAULT 0; DECLARE v_user_id BIGINT; DECLARE v_due DATE; -- 游标遍历阶梯档位 DECLARE cur_tier CURSOR FOR SELECT tier_no, lower_kwh, upper_kwh, unit_price FROM t_price_tier WHERE plan_id p_plan_id ORDER BY tier_no; DECLARE CONTINUE HANDLER FOR NOT FOUND SET v_done 1; -- 取本月用电量 SELECT usage_kwh INTO v_usage FROM t_meter_reading WHERE meter_id p_meter_id AND DATE_FORMAT(read_date, %Y-%m) p_bill_month; IF v_usage IS NULL THEN SIGNAL SQLSTATE 45000 SET MESSAGE_TEXT 该表本月无抄表记录; END IF; -- 取用户和截止日 SELECT user_id INTO v_user_id FROM t_meter WHERE meter_id p_meter_id; SET v_due LAST_DAY(CONCAT(p_bill_month, -01)); -- 按阶梯累加电费 SET v_prev 0; OPEN cur_tier; read_loop: LOOP FETCH cur_tier INTO v_tier_no, v_lower, v_upper, v_price; IF v_done 1 THEN LEAVE read_loop; END IF; IF v_usage v_lower THEN LEAVE read_loop; END IF; -- 本档计费电量 min(总用电, 本档上限) - 本档起始 SET v_curr LEAST(v_usage, COALESCE(v_upper, v_usage)) - v_lower; IF v_curr 0 THEN SET v_amount v_amount v_curr * v_price; END IF; END LOOP; CLOSE cur_tier; -- 写入账单唯一键冲突则更新 INSERT INTO t_bill (bill_no, user_id, meter_id, bill_month, usage_kwh, amount, due_date) VALUES (CONCAT(B, p_bill_month, p_meter_id), v_user_id, p_meter_id, p_bill_month, v_usage, v_amount, v_due) ON DUPLICATE KEY UPDATE usage_kwh v_usage, amount v_amount; END$$ DELIMITER ;这段逻辑的关键在阶梯累加每档只对落在该档区间内的电量计费LEAST(v_usage, COALESCE(v_upper, v_usage)) - v_lower是核心表达式。COALESCE(v_upper, v_usage)处理最高档无上限的情况。ON DUPLICATE KEY UPDATE保证重复计费不会产生两条账单靠的是账单表上(meter_id, bill_month)的唯一键。参数说明p_meter_id是电表主键p_bill_month格式必须是YYYY-MMp_plan_id指向电价方案。如果本月没有抄表记录存储过程直接抛错不会生成金额为 0 的假账单。这是血泪经验——早期版本没做这个校验结果空账单混进收费列表对账时多出一堆零元单。3.2 收款事务余额抵扣与流水写入必须原子收款环节最怕的是“钱扣了但账单没更新”或者“账单更新了但流水没记”。这两件事必须在同一个事务里完成。下面是一个收款存储过程支持预存余额抵扣和现金收款两种方式DELIMITER $$ CREATE PROCEDURE sp_pay_bill( IN p_bill_id BIGINT, IN p_pay_amount DECIMAL(12,2), IN p_pay_method TINYINT, IN p_operator_id BIGINT ) BEGIN DECLARE v_owe DECIMAL(12,2); DECLARE v_paid DECIMAL(12,2); DECLARE v_amount DECIMAL(12,2); DECLARE v_penalty DECIMAL(12,2); DECLARE v_user_id BIGINT; DECLARE v_balance DECIMAL(12,2); -- 开启事务 START TRANSACTION; -- 锁定账单行防止并发重复收款 SELECT amount, penalty, paid_amount, user_id INTO v_amount, v_penalty, v_paid, v_user_id FROM t_bill WHERE bill_id p_bill_id FOR UPDATE; SET v_owe v_amount v_penalty - v_paid; IF p_pay_amount 0 THEN SIGNAL SQLSTATE 45000 SET MESSAGE_TEXT 收款金额必须大于0; END IF; IF p_pay_amount v_owe THEN SIGNAL SQLSTATE 45000 SET MESSAGE_TEXT 收款金额超过欠费金额; END IF; -- 更新账单已收金额和状态 UPDATE t_bill SET paid_amount paid_amount p_pay_amount, status CASE WHEN paid_amount p_pay_amount amount penalty THEN 2 ELSE 1 END WHERE bill_id p_bill_id; -- 写入收款流水 INSERT INTO t_payment (bill_id, pay_amount, pay_method, operator_id) VALUES (p_bill_id, p_pay_amount, p_pay_method, p_operator_id); -- 如果是余额抵扣扣减用户余额 IF p_pay_method 4 THEN SELECT balance INTO v_balance FROM t_user WHERE user_id v_user_id FOR UPDATE; IF v_balance p_pay_amount THEN SIGNAL SQLSTATE 45000 SET MESSAGE_TEXT 预存余额不足; END IF; UPDATE t_user SET balance balance - p_pay_amount WHERE user_id v_user_id; END IF; COMMIT; END$$ DELIMITER ;这里有两个必须注意的点。第一SELECT ... FOR UPDATE锁住账单行防止两个收费窗口同时收同一笔账单导致重复抵扣。第二余额抵扣时也要锁用户行否则并发扣余额会扣成负数。事务边界从START TRANSACTION到COMMIT中间任何一步失败都回滚保证钱和账一致。参数上p_pay_method我扩展了 4 表示余额抵扣和前面的 1/2/3 区分开。实际课设里可以简化但建议保留这个分支因为它能体现你对“预存电费”场景的理解。3.3 违约金自动计算的触发器违约金按逾期天数计算常见规则是每日万分之五。用触发器在账单更新时自动算比定时任务简单课设阶段够用。DELIMITER $$ CREATE TRIGGER trg_bill_penalty BEFORE UPDATE ON t_bill FOR EACH ROW BEGIN -- 仅当账单未缴清且已过截止日时计算违约金 IF NEW.status 2 AND NEW.due_date CURDATE() THEN SET NEW.penalty ROUND(NEW.amount * 0.0005 * DATEDIFF(CURDATE(), NEW.due_date), 2); END IF; END$$ DELIMITER ;触发器逻辑简单但要注意它只在UPDATE时触发如果账单生成后一直没人动违约金不会自动更新。所以实际系统里通常配合一个每日定时任务批量刷新。课设里可以手动执行一条UPDATE t_bill SET status status WHERE ...来触发或者干脆在查询时用视图实时算。触发器适合演示“自动计算”这个概念但别把它当成唯一手段。4. 避坑与排查课设答辩前必须过的五道坎4.1 电费算不平差几分钱现象手工核算和系统算出的电费差 0.01 到 0.05 元。原因通常是浮点类型或四舍五入时机不对。解决金额字段全部用DECIMAL单价用DECIMAL(8,4)最终金额用ROUND(..., 2)统一保留两位。不要在中间步骤提前舍入累加完再舍入。4.2 抄表记录重复录入现象同一块表同一个月出现两条抄表记录计费时取到错误的一条。原因没加唯一约束。解决抄表记录表加UNIQUE KEY (meter_id, read_date)应用层插入时捕获唯一键冲突并提示“本月已抄表”。如果业务允许补抄改成(meter_id, read_date, read_seq)联合唯一。4.3 并发收款导致余额扣成负数现象两个收费员同时给同一用户做余额抵扣余额被扣两次。原因没加行锁。解决在事务里用SELECT ... FOR UPDATE锁住用户行和账单行扣减前再校验一次余额。注意锁的顺序要一致先锁账单再锁用户避免死锁。4.4 账单状态和已收金额不一致现象账单显示“已缴清”但paid_amount小于amount penalty。原因状态更新逻辑写错或者手工改过数据。解决状态不要手工维护用生成列或触发器根据paid_amount自动推导。查询时用CASE WHEN paid_amount amount penalty THEN 2 ...实时判断避免状态字段成为黑匣子。4.5 删除用户导致账单丢失现象删除一个销户用户后历史账单查不到了。原因外键没设ON DELETE RESTRICT或者用了级联删除。解决用户表加status字段做逻辑删除物理删除一律禁止。外键统一用RESTRICT账单和流水是财务数据任何情况下不能跟着用户一起消失。5. 对账与数据校验让系统自己证明自己没算错课设答辩时老师最常问的一句话是“你怎么证明你的电费算对了”。与其口头解释不如写几条对账 SQL让系统自己证明。我一般会准备三组校验查询答辩前跑一遍结果全为 0 才放心。第一组账单金额与流水汇总是否一致。-- 检查每张账单的已收金额是否等于流水汇总 SELECT b.bill_id, b.paid_amount, COALESCE(SUM(p.pay_amount), 0) AS flow_sum FROM t_bill b LEFT JOIN t_payment p ON b.bill_id p.bill_id GROUP BY b.bill_id, b.paid_amount HAVING b.paid_amount COALESCE(SUM(p.pay_amount), 0);这条查询返回空集说明账单上的已收金额和流水记录完全对得上。如果有差异要么是收款时事务没包住要么是有人手工改了账单。第二组用电量是否等于抄表差值。-- 检查账单用电量与抄表记录是否一致 SELECT b.bill_id, b.usage_kwh, r.usage_kwh AS reading_usage FROM t_bill b JOIN t_meter_reading r ON b.meter_id r.meter_id AND DATE_FORMAT(r.read_date, %Y-%m) b.bill_month WHERE b.usage_kwh r.usage_kwh;因为usage_kwh在抄表记录里是生成列这条查询理论上永远为空。如果非空说明账单写入时用了错误的数据源。第三组阶梯电价分档累加是否覆盖全部电量。-- 检查每个阶梯方案的分档是否连续无缺口 SELECT plan_id, tier_no, lower_kwh, upper_kwh, LAG(upper_kwh) OVER (PARTITION BY plan_id ORDER BY tier_no) AS prev_upper FROM t_price_tier ORDER BY plan_id, tier_no;人工看prev_upper是否等于当前行的lower_kwh如果有缺口说明阶梯配置有断档计费时会漏算电量。这个检查在新增电价方案后必做。除了这三组我还会在账单表上建一个汇总视图按账期统计应收、实收、欠费总额和收费窗口的日报表核对。对账这件事宁可多写几条 SQL也别等到答辩时被问住。我自己的习惯是每次改完计费逻辑先跑对账查询全绿了再继续写前端。这个习惯帮我省掉了至少三次返工。希望帮到你。本文还有配套的精品资源点击获取
