简介「医院管理系统数据库设计.docx」是一份面向计算机专业学生与课程设计者的数据库建模文档围绕医院信息系统HIS的组织结构、业务流程与建库要点展开适用于数据库课程设计、毕业设计选题参考及需求分析训练。文档以门诊与住院两大部门为主线梳理挂号、收费、检查、药房、病案、手术等科室的职责与数据流向给出需求分析方法与实体关系梳理思路并讨论数据完整性、一致性、安全性、并发性能、可扩展性与法规遵从等设计考量同时涉及ER图转表、外键关联、索引优化与适度冗余的取舍。整包仅含1个docx文件约398KB轻量易读可直接当作文档模板与写作框架参考。目前已有175人学习。读者能从中获得较完整的部门关系与业务流程图描述、需求分析书写范式以及把业务语言落成表结构的实践路径便于快速搭建数据库设计文档骨架。1. 接手一套半成品门诊收费模块我先翻的是那份数据库设计文档接手一套别人做了一半的门诊收费模块时和代码一起丢过来的还有一份《医院管理系统数据库设计》文档。翻完发现真正值钱的不是后面那堆字段清单而是前面几十页的业务流程——挂号处怎么收费、药房怎么向药库领药、住院病人转科时床位和医嘱怎么跟着走。这些流程决定了后面每张表长什么样、外键往哪挂。这份资料适合两类人一类是做计算机专业课程设计需要一套完整的需求分析、数据字典、数据流图骨架直接改成自己的题目另一类是真的在接手 HIS 里某个模块需要快速看懂存量表结构的来龙去脉。下面按「业务 → 表 → 约束 → 坑 → 改造」的顺序拆。2. 业务骨架拆解门诊和住院两条链路决定了你要建多少张表拿到一份数据库设计文档多数人的第一反应是直接翻到建表那一节抄字段。这个顺序是反的。文档里那些部门清单、业务活动描述看着像凑字数的前言其实它们才是表的来源——每出现一个需要长期记录信息的动作就对应一张表或一组表每出现一个只做一次的动作往往只是一条状态变更。先把业务链路捋顺后面建表的时候就不会出现「这张表为什么要存在」的疑问。这份文档的组织结构描述里点名了十几类部门门诊部门和住院部门两大类下面挂口腔科、内科、外科、皮肤科、骨科这些科室支撑部门有药库、药房、设备科、财务科、后勤仓库、门诊收费处、门诊挂号处、问讯处、住院处、检查科室、血库、病案室、手术室再加上行政部门。把这些部门当成「谁产生数据、谁消费数据」的节点来看实体就浮出来了。2.1 从组织结构读实体十几个部门反推出二十多张表从部门职责里能直接数出来的实体有这么几组。第一组是人病人、医生、护士、行政人员其中医生还要按主治医师、副主任医师、普通医师、教授副教授再分级这一层在文档里是作为「医生的职称」属性写的实际建模时如果要做排班和挂号费分级职称最好单独抽一张字典表别硬编码成字符串。第二组是物药品、设备、血液、床位。第三组是单据挂号单、门诊病历、处方、检查申请单与结果报告单、收款单、住院登记单、转科申请单、医嘱单、药品请领单、出入库单、手术申请单与通知单、病案。第四组是关系科室与医生的从属、医生与病人的诊疗关系、药品与供应商的采购关系。文档里给出的数据结构一共十五个挂号单、门诊病历、门诊处方、检查项目、订单、药品、病人、医生、处理方案、收费项目、供应商、药库、医嘱、手术、病案。这十五个是骨架但直接照抄成表会出问题最典型的是「门诊处方」这个结构组成写的是「处方号、主治医师、病人姓名、病人性别、病人年龄、处方内容」处方内容一个char(100)就装完了。这种设计在纸面上够用一旦要对账——某盒药这个月出了多少、哪个医生的处方里某类抗生素占比多少——就完全查不出来因为药品明细被压在了一个字符串里。我的处理方式是凡是文档里写成「XX 内容」「XX 记录」这种大文本字段的一律当成待拆的信号。处方拆成处方头加处方明细医嘱拆成医嘱头加医嘱明细检查单拆成申请单加结果报告病案本身可以保留为一条主记录但检查、手术、用药各自挂明细。拆完之后原本十五个结构大约会膨胀到二十五到三十张表这个量级对一个中小型医院的门诊加住院业务是合理的。2.2 门诊链路挂号、处方、收费、发药的四段式流转门诊这条链路的业务描述在文档里写得相当细值得逐句抠。初诊病人先到挂号处登记基本信息姓名、年龄、住址、联系方式复诊病人直接挂号排号挂号处同时负责病历管理。然后到收费处缴挂号费持挂号凭证去对应科室就诊。医生诊疗后开出诊断结果、处方或者检查申请单。如果是处方病人拿着处方去收费处划价交费再持收费凭证到药房取药如果是检查单同样先交费再去检查科室检查完拿到结果报告单可以回原科室复诊。药房发药之后库存减少降到一定量就向药库申领。这段流程拆成数据流就是四条挂号登记病人 → 挂号单、病历门诊医生 → 门诊挂号处、处方信息门诊医生、收费处 → 药房、检查单门诊医生 → 检查科室。文档的数据流表里也是这四条只是重复贴了一遍整理的时候去重就行。真正影响表结构的是这里面的「先交费后执行」顺序。挂号费要在就诊前收处方费和检查费要在执行前收意味着收费单不能只记一个总额挂在病人身上必须能指向具体的业务单据——挂的是哪个号、开的是哪张处方、哪张检查单。所以收费明细表至少要三个来源字段业务类型、业务单据号、金额。文档里的「收费项目」结构写的是「收费项目号、挂号费、药品费、检查费」这种一行三列的写法是把三种性质完全不同的费用塞进同一条记录退费的时候根本拆不开后面第 4 章会专门讲怎么改。还有一个容易漏的点药房向药库领药。文档写「当药房库存的药品减少到一定量的时候药房人员应到药库办理药品申领」对应的单据是药品请领单数据流是药房 → 药库。但数据结构清单里没有这个表只在数据流里出现了名字。这类「流程里提到、结构里没定义」的单据就是建表时最容易被跳过、上线后最容易被追着补的。2.3 住院链路入院排床、医嘱执行、手术与出院的状态闭环住院这条链路比门诊长得多状态也复杂得多。病人拿着入院通知单到住院处办手续登记基本信息、交预交款或押金办完之后由病区科室按就诊科室安排床位录入缴费信息病区按医生开的医嘱执行医嘱内容包括用药和检查申请病区把用药分类汇总成药品申领单统一向药库领药按时按量发给住院病人并记录发药情况检查申请单转给检查科室检查科室处理完把通知发回病区病区再通知病人去检查需要手术的病区提交手术申请给手术室手术室安排日程、准备器械材料然后把手术通知发回病区病人可以出院时先在病区办出院登记、办出科再到住院处办出院手续需要转科的在病区办转科手续转入病区重新安排床位。把这段翻译成表至少有这些住院登记单住院号、病人号、入院时间、入院科室、预交金额、床位表床位号、病区号、科室、状态、床位占用记录住院号、床位号、开始时间、结束时间转床转科都往这张表里插记录而不是改原记录、医嘱头与医嘱明细、药品申领单与明细、检查申请与结果、手术申请与手术记录、出院/转科记录。住院和门诊最大的结构差异在于「时间」和「状态」。门诊是一次性的挂号—就诊—收费—取药当天闭环状态少住院是持续多天的床位会转、科室会转、医嘱会停会改、费用是滚动记账最后统一结算。所以住院侧的表几乎都要带生效时间和失效时间费用也不能像门诊那样一单一结得有一个住院费用明细表持续累加出院时再汇总成结算单。文档里「病案」这个数据结构写的是「病案号、病人、入院科室、入院日期、入院诊断、出院日期、出院诊断」这是典型的出院后才补全的记录不能拿它当住院主表用——住院期间病案号还没生成主表得是住院登记单。维度门诊链路住院链路主键载体挂号号 / 病历号住院号生命周期当天闭环跨天可转科转床费用模式逐单收费先付后执行预交金 滚动记账出院结算核心单据挂号单、处方、检查单医嘱、申领单、手术记录、病案状态字段必要性中退号、退费高在院、转科、出院、结算这张对比表不是装饰它决定了两条链路能不能共用一套收费表和一套单据表。我的做法是共用病人、医生、药品、科室这些主数据业务单据完全分开建收费明细通过「业务类型 业务单号」统一挂到一张费用流水表上这样财务侧做日结、月结的时候只查一张表。3. 数据字典落地把 char(8) 编码翻译成可执行的 DDL文档的数据字典部分信息量很大但它是按「数据项—数据结构—数据流—数据存储—处理过程」五段分开写的同一张表在五个地方各出现一次字段名还不完全一致。落到真实库之前必须先做一次归并以数据结构里的字段组成为准用数据项里的类型长度去补全类型数据流和数据存储只用来校验有没有漏表。这里有一个绕不开的选择文档里几乎所有主键都是char(8)订单号是char(20)病区号还写成了char(10)但描述里说「8 位组成唯一编码」。这套编码规则本身没问题国内不少 HIS 确实用 8 位定长业务码。问题在于两种做法混用会造成后面无穷的麻烦——有的表拿业务码当主键有的表又自己加自增 ID外键指向就乱了。我的建议是主数据表病人、医生、药品、科室、供应商用自增或雪花 ID 做代理主键业务编码单独一列加唯一索引业务单据表挂号单、处方、医嘱、手术反过来直接用业务编码做主键因为这些单据号本身就是全局唯一的而且要打印在纸质单据上多一层映射反而增加对账成本。文档没规定 DBMS下面统一按 MySQL 8 写换 SQL Server 只需要把AUTO_INCREMENT换成IDENTITY、DATETIME换成DATETIME2其余基本不用动。3.1 三张主数据表病人、医生、药品病人表和医生表在文档里的字段高度对称都是「编号、姓名、性别、年龄、身份证号、出生日期、住址、联系方式」医生多一个职称和科室。这里有两个细节要改一是年龄不该存出生日期有了年龄随时算存了就要每年批量更新纯属给自己找活二是身份证号必须加唯一约束重复建档是门诊系统里最常见的脏数据来源同一个病人被建了三次档案病历就散了。-- 病人主表代理主键 业务编码唯一 CREATE TABLE patient ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 代理主键, patient_no CHAR(8) NOT NULL COMMENT 病人号8位业务编码, name VARCHAR(32) NOT NULL COMMENT 姓名, gender CHAR(1) NOT NULL DEFAULT U COMMENT 性别 M/F/U, birth_date DATE NULL COMMENT 出生日期年龄由此推算, id_card VARCHAR(18) NULL COMMENT 身份证号, phone VARCHAR(20) NULL COMMENT 联系方式, address VARCHAR(128) NULL COMMENT 住址, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_patient_no (patient_no), UNIQUE KEY uk_id_card (id_card), -- 防重复建档 KEY idx_name_phone (name, phone) -- 无身份证时的兜底检索 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT病人主数据;这段的重点在三个索引。uk_patient_no保证业务编码不重复因为挂号、处方、病案都要引用它uk_id_card是防重复建档的硬约束允许 NULL 是因为儿童和急诊无名氏确实可能没有身份证MySQL 的唯一索引允许多个 NULL正好符合需求idx_name_phone是为「病人报不出身份证号前台用姓名加手机号查档」这个高频场景准备的。性别用CHAR(1)存 M/F/U 而不是存「男/女」是为了兼容后续可能出现的英文界面和接口对接展示层再翻译。药品表的字段文档给的是「药品编号、药品名、规格、单位、数量、单价、金额、生产日期、保质期」。这里的坑在于「数量」和「金额」——这两个是库存和交易的结果不该放在药品主数据里。药品表只描述「这是什么药」库存数量放库存表金额放单据明细。保质期也不该存天数存生产日期加有效期末日更好因为同一批药的生产日期不同保质期天数相同但到期日不同按批次管理才查得出近效期。-- 药品主数据只描述属性不存库存和金额 CREATE TABLE drug ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, kind_no CHAR(8) NOT NULL COMMENT 药品编号, drug_name VARCHAR(64) NOT NULL COMMENT 药品名, spec VARCHAR(64) NULL COMMENT 规格如 0.25g*24片, unit VARCHAR(16) NOT NULL COMMENT 最小单位片/支/瓶, retail_price DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT 零售单价, is_active TINYINT(1) NOT NULL DEFAULT 1 COMMENT 是否在用停用不删, PRIMARY KEY (id), UNIQUE KEY uk_kind_no (kind_no), KEY idx_name (drug_name) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT药品主数据; -- 批次库存数量、效期都在这一层 CREATE TABLE drug_stock ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, drug_id BIGINT UNSIGNED NOT NULL, warehouse_id BIGINT UNSIGNED NOT NULL COMMENT 药库或药房, batch_no VARCHAR(32) NOT NULL COMMENT 生产批号, expire_date DATE NOT NULL COMMENT 有效期至, quantity INT NOT NULL DEFAULT 0 COMMENT 当前库存禁止为负, PRIMARY KEY (id), UNIQUE KEY uk_drug_wh_batch (drug_id, warehouse_id, batch_no), KEY idx_expire (expire_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT药品批次库存;把库存按批次拆开之后近效期预警、先进先出发药、按批号召回这三件事才有地方落。文档里「库存少到一定程度系统应提出警告」这条需求落地就是一条定时查询按drug_id汇总quantity和药品表里一个min_stock阈值比较。这个阈值字段我一般直接加在drug表上不单独建表。3.2 挂号单、处方头与处方明细把 char(100) 拆开挂号单在文档里的组成是「挂号号、挂号类别、主治医师、挂号人姓名、挂号科室、挂号日期」。直接照抄的问题是没有状态字段退号怎么办没有费用字段挂号费从哪来没有就诊序号同科室多个病人怎么排队我在实际项目里至少会加上状态、挂号费、支付方式、就诊序号四个字段。CREATE TABLE registration ( gh_no CHAR(8) NOT NULL COMMENT 挂号号, patient_id BIGINT UNSIGNED NOT NULL, dept_id BIGINT UNSIGNED NOT NULL COMMENT 挂号科室, doctor_id BIGINT UNSIGNED NULL COMMENT 指定医生普通号为 NULL, reg_type CHAR(2) NOT NULL COMMENT 挂号类别初诊/复诊/专家, visit_seq INT NOT NULL COMMENT 当日科室就诊序号, reg_fee DECIMAL(8,2) NOT NULL DEFAULT 0.00 COMMENT 挂号费, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待就诊 1已就诊 2已退号, reg_date DATE NOT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (gh_no), KEY idx_dept_date (dept_id, reg_date), KEY idx_patient (patient_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT门诊挂号单;visit_seq这个字段是我踩过坑之后加的——最初用自增 ID 排序叫号结果退号之后序号出现空洞屏幕上跳号病人以为被插队投诉了好几次。改成按科室、按日期单独取号之后才消停。取号本身要放在一个事务里用SELECT ... FOR UPDATE锁住当日该科室的最大序号再 1。处方拆成头和明细两张表。头表存处方号、病人、医生、科室、开方时间、状态、总金额明细存药品、数量、用法用量、单次剂量、频次、天数。文档里「处方内容 char(100)」拆开之后大概长这样CREATE TABLE prescription ( cf_no CHAR(8) NOT NULL COMMENT 处方号, patient_id BIGINT UNSIGNED NOT NULL, doctor_id BIGINT UNSIGNED NOT NULL, dept_id BIGINT UNSIGNED NOT NULL, diag_text VARCHAR(255) NULL COMMENT 临床诊断, total_amount DECIMAL(10,2) NOT NULL DEFAULT 0.00, status TINYINT NOT NULL DEFAULT 0 COMMENT 0已开 1已收费 2已发药 3已退, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (cf_no), KEY idx_patient_time (patient_id, created_at), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT门诊处方头; CREATE TABLE prescription_detail ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, cf_no CHAR(8) NOT NULL, drug_id BIGINT UNSIGNED NOT NULL, quantity INT NOT NULL COMMENT 数量, dosage VARCHAR(32) NULL COMMENT 单次剂量如 0.5g, frequency VARCHAR(16) NULL COMMENT 频次如 tid, days INT NULL COMMENT 天数, unit_price DECIMAL(10,2) NOT NULL COMMENT 开方时单价锁价用, amount DECIMAL(10,2) NOT NULL, PRIMARY KEY (id), KEY idx_cf_no (cf_no), KEY idx_drug (drug_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT处方明细;unit_price存的是开方瞬间的价格快照这一点很关键。药品调价是常态如果明细不锁价三个月后重打一张旧处方金额会跟着新价格变对账的时候就是一笔糊涂账。用法用量拆成剂量、频次、天数三列而不是一段文本是为了后续做合理用药审查——有了结构化字段才能自动判断「这个剂量超过成人上限」。3.3 医嘱与手术记录时间戳和状态字段一个都别省医嘱是住院侧的核心文档里写的是「诊断单序号、诊断类别、启动日期、处理日期、医嘱内容、主治医师、病人」。这套字段最大的问题是只有启动和处理两个时间点表达不了「长期医嘱每天执行、临时医嘱一次执行、中途停止」这几种情况。实际建模要拆成医嘱头一次开立和医嘱执行记录每次执行一条停止医嘱靠stop_time和状态位标记而不是删记录。CREATE TABLE medical_order ( order_no CHAR(8) NOT NULL COMMENT 医嘱号, admission_no CHAR(8) NOT NULL COMMENT 住院号, order_type CHAR(1) NOT NULL COMMENT L长期 T临时, content VARCHAR(255) NOT NULL COMMENT 医嘱内容, doctor_id BIGINT UNSIGNED NOT NULL, start_time DATETIME NOT NULL COMMENT 开始执行时间, stop_time DATETIME NULL COMMENT 停止时间长期医嘱用, status TINYINT NOT NULL DEFAULT 0 COMMENT 0开立 1执行中 2已停 3已作废, PRIMARY KEY (order_no), KEY idx_admission (admission_no, start_time), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT住院医嘱;手术记录同理文档写的是「手术序号、主刀医师、住院号、病人、手术名称、手术日期、手术结果、手术室」缺了麻醉方式、术前诊断、术中记录、器械材料使用。器械材料这部分在文档里是作为业务描述提到的——「手术室需将麻醉记录、术中医嘱、材料、器械的使用记录在案」——但结构清单里没有对应的表。这类耗材要单独建一张手术耗材表因为耗材是要计费的直接并进手术记录里就没法算成本。4. 约束与一致性库存、金额、状态机三处必须设防的地方设计文档里讲「数据完整性」「数据一致性」多数时候停留在一句原则。真到写代码那天这三个词要落到具体的位置上库存扣减落在UPDATE的WHERE条件里金额一致性落在触发器和事务边界上状态机落在字段枚举和状态变更日志上。这一章讲的就是这三处最容易翻车的地方。4.1 药品库存扣减唯一可靠的防线在 UPDATE 的 WHERE 里发药的典型写法是先查库存、判断够不够、够了再更新。这个顺序在单线程下没问题两个人同时发同一批药就会超卖都查到剩 10 盒都判断够都扣 6 盒最后库存变成 -2。正确做法是把判断塞进更新语句本身靠数据库的行锁保证原子性-- 发药扣减条件更新影响行数为 0 即代表库存不足 UPDATE drug_stock SET quantity quantity - :need_qty WHERE drug_id :drug_id AND warehouse_id :pharmacy_id AND batch_no :batch_no AND quantity :need_qty; -- 应用层判断affected_rows 0 时抛库存不足回滚整个事务quantity :need_qty这个条件就是防线。InnoDB 执行这条 UPDATE 时会对命中行加排他锁两个事务排队进后一个进来时quantity已经被减过条件不成立影响行数为 0业务层据此回滚。相比先SELECT再判断少了一次往返也少了一个竞态窗口。还要加一层兜底quantity列上加CHECK (quantity 0)。MySQL 8.0.16 之后支持 CHECK 约束并真正生效。这层约束平时不会触发一旦有别的代码路径绕过上面的条件更新直接改表它会立刻报错比事后对账发现负库存强得多。批次的选择逻辑也值得说一句。同一个药品可能有多个批次发药时优先发近效期的这是行业惯例也是减少报损最直接的手段。实现上就是按expire_date ASC取批次逐批扣减直到满足数量整个过程放在一个事务里。4.2 金额一致性收费项目别塞成一行账单要能重算文档里的「收费项目」结构是「收费项目号、挂号费、药品费、检查费」一行三个金额列。这种设计在只有一个病人一条记录的时候看着挺省事但它隐含了一个假设一个病人一次就诊只会产生这三种费用各一笔。现实是门诊一次开两张处方、三张检查单很常见住院更不用说一天几十条费用明细。所以收费必须做成「费用流水 结算单」两层CREATE TABLE charge_item ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, patient_id BIGINT UNSIGNED NOT NULL, biz_type CHAR(2) NOT NULL COMMENT GH挂号 CF处方 JC检查 YP药品 ZY住院, biz_no VARCHAR(20) NOT NULL COMMENT 来源业务单号, item_name VARCHAR(64) NOT NULL, amount DECIMAL(10,2) NOT NULL, pay_status TINYINT NOT NULL DEFAULT 0 COMMENT 0未付 1已付 2已退, charge_time DATETIME NULL, PRIMARY KEY (id), KEY idx_biz (biz_type, biz_no), KEY idx_patient_status (patient_id, pay_status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT费用流水;biz_type加biz_no这一对构成了「这笔钱是从哪张单子来的」的追溯链路。退费的时候按这两个字段反查把对应的处方或检查单状态改回可退同时插一条负数流水而不是删原记录。财务对账要的是可追溯的流水删记录等于把账本撕了一页。金额的另一处隐患是「头表总额」和「明细合计」不一致。处方头的total_amount必须由明细汇总写回而且要在同一个事务里完成。我的习惯是明细全部插完之后执行一条UPDATE prescription SET total_amount (SELECT SUM(amount) FROM prescription_detail WHERE cf_no ?) WHERE cf_no ?而不是在应用层算好了再传进去。应用层算和数据库存之间只要有一次并发插入数就对不上。4.3 索引与数据量一年一万张挂号单意味着什么文档在数据存储部分给了数据量估算挂号单、门诊病历、病人信息、检查单、医嘱都是每年一万张左右。这个量级对 MySQL 来说很小单表十万级完全不需要分库分表甚至不需要分区。但它揭示了一个更重要的事实这些表是「写多读也多」的每年新增一万五年就是五万加上历史查询需求索引设计不能只考虑当天。挂号单最典型的查询是「今天这个科室挂了哪些人」对应(dept_id, reg_date)联合索引第二典型的是「这个病人以前来过几次」对应patient_id单列索引。处方表的查询集中在「这个病人最近开了什么药」和「这个药这个月出了多少」前者走(patient_id, created_at)后者走明细表的drug_id。医嘱表按住院号查(admission_no, start_time)一个联合索引覆盖绝大多数场景。有一条血泪经验别给每个字段都建索引。我见过一张挂号单上建了七个单列索引写入性能掉了一半查询也没快多少。判断标准很简单——出现在WHERE、JOIN ON、ORDER BY里且选择性足够高的字段才建性别、状态这种只有两三个值的字段单独建索引基本没用放进联合索引的最左边才有意义。5. 避坑与排查从设计文档到能跑的库之间的五道坎文档写得再细落到真实库还是会走样。下面这五条是我在不同项目里反复遇到的按「现象 → 原因 → 解决」记下来遇到类似的可以直接对照排查。5.1 编码与主数据上的三处重复定义坑一同一个「供应商号」出现两个不同的别名和类型。现象建表的时候发现数据项表里既有「供应商号 别名 Gys_no 类型 char(8)」又有「供应商号 别名 Trader_no 类型 char(8)」订单表里用的又是Trader_no Int(8)。三个地方对不上外键建不起来。原因文档是多人分工写的数据项清单和订单表分别由不同的人整理没有做最后的归并校对。这种情况在小组作业里极其常见。解决以订单表和数据流里出现频率最高的那个为准统一成trader_no CHAR(8)Gys_no作为历史别名记录在字段注释里不再使用。同时把「供应商」和「生产厂家」区分开——文档里订单结构有「生产地点」字段说明采购单其实同时涉及供应商和厂家两个实体硬塞进一个字段后期会出问题。坑二病区号 char(10) 但描述写「8 位组成唯一编码」。现象按描述写 8 位校验导入历史数据时发现有一批 10 位的病区号全部被拒。原因类型长度和业务规则不一致文档没说明哪个优先。解决以类型长度为准放宽校验业务层只校验非空和唯一长度交给数据库约束。这类「描述和类型打架」的地方优先信类型因为类型是要落到 DDL 里的描述只是注释。坑三病人表和医生表的字段名不统一。现象病人表用Br_name医生表用doctor_name关联查询的时候要写一堆别名。原因文档里病人相关字段用的是拼音缩写Br_name、Br_sex、Br_age医生相关字段用的是英文doctor_no两套命名风格混在一起。解决建库之前统一成一套。我的做法是全部改成下划线英文patient_name、doctor_name拼音缩写在注释里保留一份对照方便老系统对接时查。这一步看着琐碎但不做的话后面每写一个 JOIN 都要翻一次文档。5.2 流程状态与库存口径上的两处断链坑四挂号单没有状态退号退费无从下手。现象上线第一周就遇到病人挂完号不想看了要退前台改了金额字段结果日结报表和实际收款差了几十块。原因文档的挂号单结构里只有「挂号号、类别、医师、姓名、科室、日期」完全没有状态和费用字段。业务描述里也没提退号流程。解决加status字段待就诊/已就诊/已退号和reg_fee退号走状态变更加一条负数费用流水不删挂号记录、不改原金额。同时补一条约束已就诊的挂号单不允许退号只能走退费流程。这类「业务描述里没写、但现实中一定会发生」的反向流程是设计文档最容易漏的部分建模时要把每个正向流程都问一句「反着来怎么办」。坑五药房和药库是两套库存但没有调拨单据表。现象药房库存对不上查了半天发现是药房向药库领药的时候直接改了两边的数量中间没有任何单据谁在什么时候领了多少完全查不到。原因文档的数据流里提到了「药品请领单药房 → 药库」但数据结构清单里没有定义这张表开发的时候图省事就跳过了。解决补一张请领单主表加明细表字段至少包括请领单号、请领药房、目标药库、状态待审/已发/已收、申请时间、发药时间。库存变更必须挂在这张单上——药库出库、药房入库两条流水对应同一张单数量对不上立刻能定位到是哪一步断的。这条经验适用范围很广凡是涉及两个库存地点之间转移的中间一定要有一张单据表哪怕业务上只是一步操作。5.3 权限与审计的缺失坑六文档要求分级访问但模型里没有任何权限表。现象需求分析里明确写了「系统应对不同的数据设置不同的访问级别限制访问用户可查询和处理数据的类别和内容」「应对不同用户设置不同的权限」但翻遍数据结构只有医生、病人这些业务实体没有用户、角色、权限。原因需求分析和数据库设计脱节。写需求的人想到了写结构的人没接住。解决补三张表——用户表登录名、密码哈希、关联的员工 ID、角色表、用户角色关联表再补一张角色权限表角色、资源、操作。权限的粒度按「模块 操作」来比如「药房 发药」「收费处 退费」不要细到字段级字段级权限在业务系统里维护成本极高收益很小。另外建议加一张操作日志表记录谁在什么时候改了哪张表的哪条记录。医疗数据一旦出纠纷没有操作日志就是黑匣子说不清楚。6. 二次开发在这套模型上长出扩展模块拿到这套设计之后真正的工作才刚开始。我一般的做法是先跑通「最小闭环」病人建档 → 挂号 → 开处方 → 收费 → 发药这五步能连通、库存和金额对得上再往上加检查、住院、手术。加模块的时候按下面的顺序走返工最少。第一先加表再加代码。每加一个新模块先写迁移脚本把建表和索引一次写全跑通了再写业务代码。迁移脚本按日期编号存放只增不改已经上过生产的那份永远不动。我给个模板-- V20240601__add_role_permission.sql CREATE TABLE sys_role ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, role_code VARCHAR(32) NOT NULL COMMENT 角色编码, role_name VARCHAR(64) NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_role_code (role_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE sys_role_permission ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, role_id BIGINT UNSIGNED NOT NULL, resource VARCHAR(64) NOT NULL COMMENT 模块如 pharmacy.dispense, action VARCHAR(16) NOT NULL COMMENT 操作如 read/write/audit, PRIMARY KEY (id), UNIQUE KEY uk_role_res_act (role_id, resource, action) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;第二验证方法要能回放。写一个造数脚本模拟一百个病人走完整链路最后校验三件事所有处方的头表总额等于明细合计、所有发药记录扣减的库存总量等于药品出库单总量、所有费用流水的合计等于结算单金额。这三条任何一条对不上说明某个环节的事务边界有问题。第三改结构之前先看影响面。改一个字段类型先查这个字段被哪些外键、索引、视图引用再看有没有历史数据能兼容。我习惯在本地库上用SHOW CREATE TABLE把所有涉及的表导出来对比一遍而不是凭记忆判断。扩展方向需要新增的表不需要动的表权限与审计用户、角色、权限、操作日志全部业务表医保结算医保目录、结算单、对账流水处方、检查单只加字段报表统计汇总宽表或物化视图流水类表排队叫号队列、叫号记录挂号单复用 visit_seq最后说个教训。早些年我改一套类似的库觉得「就加个字段加完就完事了」直接在测试库上改完就同步到另一个环境结果忘了那个环境有张视图依赖这张表的字段顺序视图直接失效第二天门诊挂号全部报错。从那以后我每次改表结构都强制走一遍迁移脚本本地跑通、测试库跑通、比对SHOW CREATE TABLE确认一致才敢往下一个环境推。这套流程多花十分钟省下的是半夜被叫起来的机会。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/11/4 8:39:56 · 阅读 1.2k 从业务链路到MySQL表结构：门诊收费模块数据库设计实战
简介「医院管理系统数据库设计.docx」是一份面向计算机专业学生与课程设计者的数据库建模文档围绕医院信息系统HIS的组织结构、业务流程与建库要点展开适用于数据库课程设计、毕业设计选题参考及需求分析训练。文档以门诊与住院两大部门为主线梳理挂号、收费、检查、药房、病案、手术等科室的职责与数据流向给出需求分析方法与实体关系梳理思路并讨论数据完整性、一致性、安全性、并发性能、可扩展性与法规遵从等设计考量同时涉及ER图转表、外键关联、索引优化与适度冗余的取舍。整包仅含1个docx文件约398KB轻量易读可直接当作文档模板与写作框架参考。目前已有175人学习。读者能从中获得较完整的部门关系与业务流程图描述、需求分析书写范式以及把业务语言落成表结构的实践路径便于快速搭建数据库设计文档骨架。1. 接手一套半成品门诊收费模块我先翻的是那份数据库设计文档接手一套别人做了一半的门诊收费模块时和代码一起丢过来的还有一份《医院管理系统数据库设计》文档。翻完发现真正值钱的不是后面那堆字段清单而是前面几十页的业务流程——挂号处怎么收费、药房怎么向药库领药、住院病人转科时床位和医嘱怎么跟着走。这些流程决定了后面每张表长什么样、外键往哪挂。这份资料适合两类人一类是做计算机专业课程设计需要一套完整的需求分析、数据字典、数据流图骨架直接改成自己的题目另一类是真的在接手 HIS 里某个模块需要快速看懂存量表结构的来龙去脉。下面按「业务 → 表 → 约束 → 坑 → 改造」的顺序拆。2. 业务骨架拆解门诊和住院两条链路决定了你要建多少张表拿到一份数据库设计文档多数人的第一反应是直接翻到建表那一节抄字段。这个顺序是反的。文档里那些部门清单、业务活动描述看着像凑字数的前言其实它们才是表的来源——每出现一个需要长期记录信息的动作就对应一张表或一组表每出现一个只做一次的动作往往只是一条状态变更。先把业务链路捋顺后面建表的时候就不会出现「这张表为什么要存在」的疑问。这份文档的组织结构描述里点名了十几类部门门诊部门和住院部门两大类下面挂口腔科、内科、外科、皮肤科、骨科这些科室支撑部门有药库、药房、设备科、财务科、后勤仓库、门诊收费处、门诊挂号处、问讯处、住院处、检查科室、血库、病案室、手术室再加上行政部门。把这些部门当成「谁产生数据、谁消费数据」的节点来看实体就浮出来了。2.1 从组织结构读实体十几个部门反推出二十多张表从部门职责里能直接数出来的实体有这么几组。第一组是人病人、医生、护士、行政人员其中医生还要按主治医师、副主任医师、普通医师、教授副教授再分级这一层在文档里是作为「医生的职称」属性写的实际建模时如果要做排班和挂号费分级职称最好单独抽一张字典表别硬编码成字符串。第二组是物药品、设备、血液、床位。第三组是单据挂号单、门诊病历、处方、检查申请单与结果报告单、收款单、住院登记单、转科申请单、医嘱单、药品请领单、出入库单、手术申请单与通知单、病案。第四组是关系科室与医生的从属、医生与病人的诊疗关系、药品与供应商的采购关系。文档里给出的数据结构一共十五个挂号单、门诊病历、门诊处方、检查项目、订单、药品、病人、医生、处理方案、收费项目、供应商、药库、医嘱、手术、病案。这十五个是骨架但直接照抄成表会出问题最典型的是「门诊处方」这个结构组成写的是「处方号、主治医师、病人姓名、病人性别、病人年龄、处方内容」处方内容一个char(100)就装完了。这种设计在纸面上够用一旦要对账——某盒药这个月出了多少、哪个医生的处方里某类抗生素占比多少——就完全查不出来因为药品明细被压在了一个字符串里。我的处理方式是凡是文档里写成「XX 内容」「XX 记录」这种大文本字段的一律当成待拆的信号。处方拆成处方头加处方明细医嘱拆成医嘱头加医嘱明细检查单拆成申请单加结果报告病案本身可以保留为一条主记录但检查、手术、用药各自挂明细。拆完之后原本十五个结构大约会膨胀到二十五到三十张表这个量级对一个中小型医院的门诊加住院业务是合理的。2.2 门诊链路挂号、处方、收费、发药的四段式流转门诊这条链路的业务描述在文档里写得相当细值得逐句抠。初诊病人先到挂号处登记基本信息姓名、年龄、住址、联系方式复诊病人直接挂号排号挂号处同时负责病历管理。然后到收费处缴挂号费持挂号凭证去对应科室就诊。医生诊疗后开出诊断结果、处方或者检查申请单。如果是处方病人拿着处方去收费处划价交费再持收费凭证到药房取药如果是检查单同样先交费再去检查科室检查完拿到结果报告单可以回原科室复诊。药房发药之后库存减少降到一定量就向药库申领。这段流程拆成数据流就是四条挂号登记病人 → 挂号单、病历门诊医生 → 门诊挂号处、处方信息门诊医生、收费处 → 药房、检查单门诊医生 → 检查科室。文档的数据流表里也是这四条只是重复贴了一遍整理的时候去重就行。真正影响表结构的是这里面的「先交费后执行」顺序。挂号费要在就诊前收处方费和检查费要在执行前收意味着收费单不能只记一个总额挂在病人身上必须能指向具体的业务单据——挂的是哪个号、开的是哪张处方、哪张检查单。所以收费明细表至少要三个来源字段业务类型、业务单据号、金额。文档里的「收费项目」结构写的是「收费项目号、挂号费、药品费、检查费」这种一行三列的写法是把三种性质完全不同的费用塞进同一条记录退费的时候根本拆不开后面第 4 章会专门讲怎么改。还有一个容易漏的点药房向药库领药。文档写「当药房库存的药品减少到一定量的时候药房人员应到药库办理药品申领」对应的单据是药品请领单数据流是药房 → 药库。但数据结构清单里没有这个表只在数据流里出现了名字。这类「流程里提到、结构里没定义」的单据就是建表时最容易被跳过、上线后最容易被追着补的。2.3 住院链路入院排床、医嘱执行、手术与出院的状态闭环住院这条链路比门诊长得多状态也复杂得多。病人拿着入院通知单到住院处办手续登记基本信息、交预交款或押金办完之后由病区科室按就诊科室安排床位录入缴费信息病区按医生开的医嘱执行医嘱内容包括用药和检查申请病区把用药分类汇总成药品申领单统一向药库领药按时按量发给住院病人并记录发药情况检查申请单转给检查科室检查科室处理完把通知发回病区病区再通知病人去检查需要手术的病区提交手术申请给手术室手术室安排日程、准备器械材料然后把手术通知发回病区病人可以出院时先在病区办出院登记、办出科再到住院处办出院手续需要转科的在病区办转科手续转入病区重新安排床位。把这段翻译成表至少有这些住院登记单住院号、病人号、入院时间、入院科室、预交金额、床位表床位号、病区号、科室、状态、床位占用记录住院号、床位号、开始时间、结束时间转床转科都往这张表里插记录而不是改原记录、医嘱头与医嘱明细、药品申领单与明细、检查申请与结果、手术申请与手术记录、出院/转科记录。住院和门诊最大的结构差异在于「时间」和「状态」。门诊是一次性的挂号—就诊—收费—取药当天闭环状态少住院是持续多天的床位会转、科室会转、医嘱会停会改、费用是滚动记账最后统一结算。所以住院侧的表几乎都要带生效时间和失效时间费用也不能像门诊那样一单一结得有一个住院费用明细表持续累加出院时再汇总成结算单。文档里「病案」这个数据结构写的是「病案号、病人、入院科室、入院日期、入院诊断、出院日期、出院诊断」这是典型的出院后才补全的记录不能拿它当住院主表用——住院期间病案号还没生成主表得是住院登记单。维度门诊链路住院链路主键载体挂号号 / 病历号住院号生命周期当天闭环跨天可转科转床费用模式逐单收费先付后执行预交金 滚动记账出院结算核心单据挂号单、处方、检查单医嘱、申领单、手术记录、病案状态字段必要性中退号、退费高在院、转科、出院、结算这张对比表不是装饰它决定了两条链路能不能共用一套收费表和一套单据表。我的做法是共用病人、医生、药品、科室这些主数据业务单据完全分开建收费明细通过「业务类型 业务单号」统一挂到一张费用流水表上这样财务侧做日结、月结的时候只查一张表。3. 数据字典落地把 char(8) 编码翻译成可执行的 DDL文档的数据字典部分信息量很大但它是按「数据项—数据结构—数据流—数据存储—处理过程」五段分开写的同一张表在五个地方各出现一次字段名还不完全一致。落到真实库之前必须先做一次归并以数据结构里的字段组成为准用数据项里的类型长度去补全类型数据流和数据存储只用来校验有没有漏表。这里有一个绕不开的选择文档里几乎所有主键都是char(8)订单号是char(20)病区号还写成了char(10)但描述里说「8 位组成唯一编码」。这套编码规则本身没问题国内不少 HIS 确实用 8 位定长业务码。问题在于两种做法混用会造成后面无穷的麻烦——有的表拿业务码当主键有的表又自己加自增 ID外键指向就乱了。我的建议是主数据表病人、医生、药品、科室、供应商用自增或雪花 ID 做代理主键业务编码单独一列加唯一索引业务单据表挂号单、处方、医嘱、手术反过来直接用业务编码做主键因为这些单据号本身就是全局唯一的而且要打印在纸质单据上多一层映射反而增加对账成本。文档没规定 DBMS下面统一按 MySQL 8 写换 SQL Server 只需要把AUTO_INCREMENT换成IDENTITY、DATETIME换成DATETIME2其余基本不用动。3.1 三张主数据表病人、医生、药品病人表和医生表在文档里的字段高度对称都是「编号、姓名、性别、年龄、身份证号、出生日期、住址、联系方式」医生多一个职称和科室。这里有两个细节要改一是年龄不该存出生日期有了年龄随时算存了就要每年批量更新纯属给自己找活二是身份证号必须加唯一约束重复建档是门诊系统里最常见的脏数据来源同一个病人被建了三次档案病历就散了。-- 病人主表代理主键 业务编码唯一 CREATE TABLE patient ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 代理主键, patient_no CHAR(8) NOT NULL COMMENT 病人号8位业务编码, name VARCHAR(32) NOT NULL COMMENT 姓名, gender CHAR(1) NOT NULL DEFAULT U COMMENT 性别 M/F/U, birth_date DATE NULL COMMENT 出生日期年龄由此推算, id_card VARCHAR(18) NULL COMMENT 身份证号, phone VARCHAR(20) NULL COMMENT 联系方式, address VARCHAR(128) NULL COMMENT 住址, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_patient_no (patient_no), UNIQUE KEY uk_id_card (id_card), -- 防重复建档 KEY idx_name_phone (name, phone) -- 无身份证时的兜底检索 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT病人主数据;这段的重点在三个索引。uk_patient_no保证业务编码不重复因为挂号、处方、病案都要引用它uk_id_card是防重复建档的硬约束允许 NULL 是因为儿童和急诊无名氏确实可能没有身份证MySQL 的唯一索引允许多个 NULL正好符合需求idx_name_phone是为「病人报不出身份证号前台用姓名加手机号查档」这个高频场景准备的。性别用CHAR(1)存 M/F/U 而不是存「男/女」是为了兼容后续可能出现的英文界面和接口对接展示层再翻译。药品表的字段文档给的是「药品编号、药品名、规格、单位、数量、单价、金额、生产日期、保质期」。这里的坑在于「数量」和「金额」——这两个是库存和交易的结果不该放在药品主数据里。药品表只描述「这是什么药」库存数量放库存表金额放单据明细。保质期也不该存天数存生产日期加有效期末日更好因为同一批药的生产日期不同保质期天数相同但到期日不同按批次管理才查得出近效期。-- 药品主数据只描述属性不存库存和金额 CREATE TABLE drug ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, kind_no CHAR(8) NOT NULL COMMENT 药品编号, drug_name VARCHAR(64) NOT NULL COMMENT 药品名, spec VARCHAR(64) NULL COMMENT 规格如 0.25g*24片, unit VARCHAR(16) NOT NULL COMMENT 最小单位片/支/瓶, retail_price DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT 零售单价, is_active TINYINT(1) NOT NULL DEFAULT 1 COMMENT 是否在用停用不删, PRIMARY KEY (id), UNIQUE KEY uk_kind_no (kind_no), KEY idx_name (drug_name) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT药品主数据; -- 批次库存数量、效期都在这一层 CREATE TABLE drug_stock ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, drug_id BIGINT UNSIGNED NOT NULL, warehouse_id BIGINT UNSIGNED NOT NULL COMMENT 药库或药房, batch_no VARCHAR(32) NOT NULL COMMENT 生产批号, expire_date DATE NOT NULL COMMENT 有效期至, quantity INT NOT NULL DEFAULT 0 COMMENT 当前库存禁止为负, PRIMARY KEY (id), UNIQUE KEY uk_drug_wh_batch (drug_id, warehouse_id, batch_no), KEY idx_expire (expire_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT药品批次库存;把库存按批次拆开之后近效期预警、先进先出发药、按批号召回这三件事才有地方落。文档里「库存少到一定程度系统应提出警告」这条需求落地就是一条定时查询按drug_id汇总quantity和药品表里一个min_stock阈值比较。这个阈值字段我一般直接加在drug表上不单独建表。3.2 挂号单、处方头与处方明细把 char(100) 拆开挂号单在文档里的组成是「挂号号、挂号类别、主治医师、挂号人姓名、挂号科室、挂号日期」。直接照抄的问题是没有状态字段退号怎么办没有费用字段挂号费从哪来没有就诊序号同科室多个病人怎么排队我在实际项目里至少会加上状态、挂号费、支付方式、就诊序号四个字段。CREATE TABLE registration ( gh_no CHAR(8) NOT NULL COMMENT 挂号号, patient_id BIGINT UNSIGNED NOT NULL, dept_id BIGINT UNSIGNED NOT NULL COMMENT 挂号科室, doctor_id BIGINT UNSIGNED NULL COMMENT 指定医生普通号为 NULL, reg_type CHAR(2) NOT NULL COMMENT 挂号类别初诊/复诊/专家, visit_seq INT NOT NULL COMMENT 当日科室就诊序号, reg_fee DECIMAL(8,2) NOT NULL DEFAULT 0.00 COMMENT 挂号费, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待就诊 1已就诊 2已退号, reg_date DATE NOT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (gh_no), KEY idx_dept_date (dept_id, reg_date), KEY idx_patient (patient_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT门诊挂号单;visit_seq这个字段是我踩过坑之后加的——最初用自增 ID 排序叫号结果退号之后序号出现空洞屏幕上跳号病人以为被插队投诉了好几次。改成按科室、按日期单独取号之后才消停。取号本身要放在一个事务里用SELECT ... FOR UPDATE锁住当日该科室的最大序号再 1。处方拆成头和明细两张表。头表存处方号、病人、医生、科室、开方时间、状态、总金额明细存药品、数量、用法用量、单次剂量、频次、天数。文档里「处方内容 char(100)」拆开之后大概长这样CREATE TABLE prescription ( cf_no CHAR(8) NOT NULL COMMENT 处方号, patient_id BIGINT UNSIGNED NOT NULL, doctor_id BIGINT UNSIGNED NOT NULL, dept_id BIGINT UNSIGNED NOT NULL, diag_text VARCHAR(255) NULL COMMENT 临床诊断, total_amount DECIMAL(10,2) NOT NULL DEFAULT 0.00, status TINYINT NOT NULL DEFAULT 0 COMMENT 0已开 1已收费 2已发药 3已退, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (cf_no), KEY idx_patient_time (patient_id, created_at), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT门诊处方头; CREATE TABLE prescription_detail ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, cf_no CHAR(8) NOT NULL, drug_id BIGINT UNSIGNED NOT NULL, quantity INT NOT NULL COMMENT 数量, dosage VARCHAR(32) NULL COMMENT 单次剂量如 0.5g, frequency VARCHAR(16) NULL COMMENT 频次如 tid, days INT NULL COMMENT 天数, unit_price DECIMAL(10,2) NOT NULL COMMENT 开方时单价锁价用, amount DECIMAL(10,2) NOT NULL, PRIMARY KEY (id), KEY idx_cf_no (cf_no), KEY idx_drug (drug_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT处方明细;unit_price存的是开方瞬间的价格快照这一点很关键。药品调价是常态如果明细不锁价三个月后重打一张旧处方金额会跟着新价格变对账的时候就是一笔糊涂账。用法用量拆成剂量、频次、天数三列而不是一段文本是为了后续做合理用药审查——有了结构化字段才能自动判断「这个剂量超过成人上限」。3.3 医嘱与手术记录时间戳和状态字段一个都别省医嘱是住院侧的核心文档里写的是「诊断单序号、诊断类别、启动日期、处理日期、医嘱内容、主治医师、病人」。这套字段最大的问题是只有启动和处理两个时间点表达不了「长期医嘱每天执行、临时医嘱一次执行、中途停止」这几种情况。实际建模要拆成医嘱头一次开立和医嘱执行记录每次执行一条停止医嘱靠stop_time和状态位标记而不是删记录。CREATE TABLE medical_order ( order_no CHAR(8) NOT NULL COMMENT 医嘱号, admission_no CHAR(8) NOT NULL COMMENT 住院号, order_type CHAR(1) NOT NULL COMMENT L长期 T临时, content VARCHAR(255) NOT NULL COMMENT 医嘱内容, doctor_id BIGINT UNSIGNED NOT NULL, start_time DATETIME NOT NULL COMMENT 开始执行时间, stop_time DATETIME NULL COMMENT 停止时间长期医嘱用, status TINYINT NOT NULL DEFAULT 0 COMMENT 0开立 1执行中 2已停 3已作废, PRIMARY KEY (order_no), KEY idx_admission (admission_no, start_time), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT住院医嘱;手术记录同理文档写的是「手术序号、主刀医师、住院号、病人、手术名称、手术日期、手术结果、手术室」缺了麻醉方式、术前诊断、术中记录、器械材料使用。器械材料这部分在文档里是作为业务描述提到的——「手术室需将麻醉记录、术中医嘱、材料、器械的使用记录在案」——但结构清单里没有对应的表。这类耗材要单独建一张手术耗材表因为耗材是要计费的直接并进手术记录里就没法算成本。4. 约束与一致性库存、金额、状态机三处必须设防的地方设计文档里讲「数据完整性」「数据一致性」多数时候停留在一句原则。真到写代码那天这三个词要落到具体的位置上库存扣减落在UPDATE的WHERE条件里金额一致性落在触发器和事务边界上状态机落在字段枚举和状态变更日志上。这一章讲的就是这三处最容易翻车的地方。4.1 药品库存扣减唯一可靠的防线在 UPDATE 的 WHERE 里发药的典型写法是先查库存、判断够不够、够了再更新。这个顺序在单线程下没问题两个人同时发同一批药就会超卖都查到剩 10 盒都判断够都扣 6 盒最后库存变成 -2。正确做法是把判断塞进更新语句本身靠数据库的行锁保证原子性-- 发药扣减条件更新影响行数为 0 即代表库存不足 UPDATE drug_stock SET quantity quantity - :need_qty WHERE drug_id :drug_id AND warehouse_id :pharmacy_id AND batch_no :batch_no AND quantity :need_qty; -- 应用层判断affected_rows 0 时抛库存不足回滚整个事务quantity :need_qty这个条件就是防线。InnoDB 执行这条 UPDATE 时会对命中行加排他锁两个事务排队进后一个进来时quantity已经被减过条件不成立影响行数为 0业务层据此回滚。相比先SELECT再判断少了一次往返也少了一个竞态窗口。还要加一层兜底quantity列上加CHECK (quantity 0)。MySQL 8.0.16 之后支持 CHECK 约束并真正生效。这层约束平时不会触发一旦有别的代码路径绕过上面的条件更新直接改表它会立刻报错比事后对账发现负库存强得多。批次的选择逻辑也值得说一句。同一个药品可能有多个批次发药时优先发近效期的这是行业惯例也是减少报损最直接的手段。实现上就是按expire_date ASC取批次逐批扣减直到满足数量整个过程放在一个事务里。4.2 金额一致性收费项目别塞成一行账单要能重算文档里的「收费项目」结构是「收费项目号、挂号费、药品费、检查费」一行三个金额列。这种设计在只有一个病人一条记录的时候看着挺省事但它隐含了一个假设一个病人一次就诊只会产生这三种费用各一笔。现实是门诊一次开两张处方、三张检查单很常见住院更不用说一天几十条费用明细。所以收费必须做成「费用流水 结算单」两层CREATE TABLE charge_item ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, patient_id BIGINT UNSIGNED NOT NULL, biz_type CHAR(2) NOT NULL COMMENT GH挂号 CF处方 JC检查 YP药品 ZY住院, biz_no VARCHAR(20) NOT NULL COMMENT 来源业务单号, item_name VARCHAR(64) NOT NULL, amount DECIMAL(10,2) NOT NULL, pay_status TINYINT NOT NULL DEFAULT 0 COMMENT 0未付 1已付 2已退, charge_time DATETIME NULL, PRIMARY KEY (id), KEY idx_biz (biz_type, biz_no), KEY idx_patient_status (patient_id, pay_status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT费用流水;biz_type加biz_no这一对构成了「这笔钱是从哪张单子来的」的追溯链路。退费的时候按这两个字段反查把对应的处方或检查单状态改回可退同时插一条负数流水而不是删原记录。财务对账要的是可追溯的流水删记录等于把账本撕了一页。金额的另一处隐患是「头表总额」和「明细合计」不一致。处方头的total_amount必须由明细汇总写回而且要在同一个事务里完成。我的习惯是明细全部插完之后执行一条UPDATE prescription SET total_amount (SELECT SUM(amount) FROM prescription_detail WHERE cf_no ?) WHERE cf_no ?而不是在应用层算好了再传进去。应用层算和数据库存之间只要有一次并发插入数就对不上。4.3 索引与数据量一年一万张挂号单意味着什么文档在数据存储部分给了数据量估算挂号单、门诊病历、病人信息、检查单、医嘱都是每年一万张左右。这个量级对 MySQL 来说很小单表十万级完全不需要分库分表甚至不需要分区。但它揭示了一个更重要的事实这些表是「写多读也多」的每年新增一万五年就是五万加上历史查询需求索引设计不能只考虑当天。挂号单最典型的查询是「今天这个科室挂了哪些人」对应(dept_id, reg_date)联合索引第二典型的是「这个病人以前来过几次」对应patient_id单列索引。处方表的查询集中在「这个病人最近开了什么药」和「这个药这个月出了多少」前者走(patient_id, created_at)后者走明细表的drug_id。医嘱表按住院号查(admission_no, start_time)一个联合索引覆盖绝大多数场景。有一条血泪经验别给每个字段都建索引。我见过一张挂号单上建了七个单列索引写入性能掉了一半查询也没快多少。判断标准很简单——出现在WHERE、JOIN ON、ORDER BY里且选择性足够高的字段才建性别、状态这种只有两三个值的字段单独建索引基本没用放进联合索引的最左边才有意义。5. 避坑与排查从设计文档到能跑的库之间的五道坎文档写得再细落到真实库还是会走样。下面这五条是我在不同项目里反复遇到的按「现象 → 原因 → 解决」记下来遇到类似的可以直接对照排查。5.1 编码与主数据上的三处重复定义坑一同一个「供应商号」出现两个不同的别名和类型。现象建表的时候发现数据项表里既有「供应商号 别名 Gys_no 类型 char(8)」又有「供应商号 别名 Trader_no 类型 char(8)」订单表里用的又是Trader_no Int(8)。三个地方对不上外键建不起来。原因文档是多人分工写的数据项清单和订单表分别由不同的人整理没有做最后的归并校对。这种情况在小组作业里极其常见。解决以订单表和数据流里出现频率最高的那个为准统一成trader_no CHAR(8)Gys_no作为历史别名记录在字段注释里不再使用。同时把「供应商」和「生产厂家」区分开——文档里订单结构有「生产地点」字段说明采购单其实同时涉及供应商和厂家两个实体硬塞进一个字段后期会出问题。坑二病区号 char(10) 但描述写「8 位组成唯一编码」。现象按描述写 8 位校验导入历史数据时发现有一批 10 位的病区号全部被拒。原因类型长度和业务规则不一致文档没说明哪个优先。解决以类型长度为准放宽校验业务层只校验非空和唯一长度交给数据库约束。这类「描述和类型打架」的地方优先信类型因为类型是要落到 DDL 里的描述只是注释。坑三病人表和医生表的字段名不统一。现象病人表用Br_name医生表用doctor_name关联查询的时候要写一堆别名。原因文档里病人相关字段用的是拼音缩写Br_name、Br_sex、Br_age医生相关字段用的是英文doctor_no两套命名风格混在一起。解决建库之前统一成一套。我的做法是全部改成下划线英文patient_name、doctor_name拼音缩写在注释里保留一份对照方便老系统对接时查。这一步看着琐碎但不做的话后面每写一个 JOIN 都要翻一次文档。5.2 流程状态与库存口径上的两处断链坑四挂号单没有状态退号退费无从下手。现象上线第一周就遇到病人挂完号不想看了要退前台改了金额字段结果日结报表和实际收款差了几十块。原因文档的挂号单结构里只有「挂号号、类别、医师、姓名、科室、日期」完全没有状态和费用字段。业务描述里也没提退号流程。解决加status字段待就诊/已就诊/已退号和reg_fee退号走状态变更加一条负数费用流水不删挂号记录、不改原金额。同时补一条约束已就诊的挂号单不允许退号只能走退费流程。这类「业务描述里没写、但现实中一定会发生」的反向流程是设计文档最容易漏的部分建模时要把每个正向流程都问一句「反着来怎么办」。坑五药房和药库是两套库存但没有调拨单据表。现象药房库存对不上查了半天发现是药房向药库领药的时候直接改了两边的数量中间没有任何单据谁在什么时候领了多少完全查不到。原因文档的数据流里提到了「药品请领单药房 → 药库」但数据结构清单里没有定义这张表开发的时候图省事就跳过了。解决补一张请领单主表加明细表字段至少包括请领单号、请领药房、目标药库、状态待审/已发/已收、申请时间、发药时间。库存变更必须挂在这张单上——药库出库、药房入库两条流水对应同一张单数量对不上立刻能定位到是哪一步断的。这条经验适用范围很广凡是涉及两个库存地点之间转移的中间一定要有一张单据表哪怕业务上只是一步操作。5.3 权限与审计的缺失坑六文档要求分级访问但模型里没有任何权限表。现象需求分析里明确写了「系统应对不同的数据设置不同的访问级别限制访问用户可查询和处理数据的类别和内容」「应对不同用户设置不同的权限」但翻遍数据结构只有医生、病人这些业务实体没有用户、角色、权限。原因需求分析和数据库设计脱节。写需求的人想到了写结构的人没接住。解决补三张表——用户表登录名、密码哈希、关联的员工 ID、角色表、用户角色关联表再补一张角色权限表角色、资源、操作。权限的粒度按「模块 操作」来比如「药房 发药」「收费处 退费」不要细到字段级字段级权限在业务系统里维护成本极高收益很小。另外建议加一张操作日志表记录谁在什么时候改了哪张表的哪条记录。医疗数据一旦出纠纷没有操作日志就是黑匣子说不清楚。6. 二次开发在这套模型上长出扩展模块拿到这套设计之后真正的工作才刚开始。我一般的做法是先跑通「最小闭环」病人建档 → 挂号 → 开处方 → 收费 → 发药这五步能连通、库存和金额对得上再往上加检查、住院、手术。加模块的时候按下面的顺序走返工最少。第一先加表再加代码。每加一个新模块先写迁移脚本把建表和索引一次写全跑通了再写业务代码。迁移脚本按日期编号存放只增不改已经上过生产的那份永远不动。我给个模板-- V20240601__add_role_permission.sql CREATE TABLE sys_role ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, role_code VARCHAR(32) NOT NULL COMMENT 角色编码, role_name VARCHAR(64) NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_role_code (role_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE sys_role_permission ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, role_id BIGINT UNSIGNED NOT NULL, resource VARCHAR(64) NOT NULL COMMENT 模块如 pharmacy.dispense, action VARCHAR(16) NOT NULL COMMENT 操作如 read/write/audit, PRIMARY KEY (id), UNIQUE KEY uk_role_res_act (role_id, resource, action) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;第二验证方法要能回放。写一个造数脚本模拟一百个病人走完整链路最后校验三件事所有处方的头表总额等于明细合计、所有发药记录扣减的库存总量等于药品出库单总量、所有费用流水的合计等于结算单金额。这三条任何一条对不上说明某个环节的事务边界有问题。第三改结构之前先看影响面。改一个字段类型先查这个字段被哪些外键、索引、视图引用再看有没有历史数据能兼容。我习惯在本地库上用SHOW CREATE TABLE把所有涉及的表导出来对比一遍而不是凭记忆判断。扩展方向需要新增的表不需要动的表权限与审计用户、角色、权限、操作日志全部业务表医保结算医保目录、结算单、对账流水处方、检查单只加字段报表统计汇总宽表或物化视图流水类表排队叫号队列、叫号记录挂号单复用 visit_seq最后说个教训。早些年我改一套类似的库觉得「就加个字段加完就完事了」直接在测试库上改完就同步到另一个环境结果忘了那个环境有张视图依赖这张表的字段顺序视图直接失效第二天门诊挂号全部报错。从那以后我每次改表结构都强制走一遍迁移脚本本地跑通、测试库跑通、比对SHOW CREATE TABLE确认一致才敢往下一个环境推。这套流程多花十分钟省下的是半夜被叫起来的机会。希望帮到你。本文还有配套的精品资源点击获取