企业官网建设流程全解析

博主介绍：✌ 专注于VUE,小程序，安卓，Java,python,物联网专业，有18年开发经验，长年从事毕业指导，项目实战✌选取一个适合的毕业设计题目很重要。✌关注✌私信我✌具体的问题，我会尽力帮助你。

一、研究目的

在当前医疗信息化快速发展的背景下，医院预约挂号系统作为实现医疗资源高效配置与患者就诊体验优化的关键技术手段，其设计与实现质量直接影响着医疗服务的整体水平。传统的预约挂号模式普遍存在信息孤岛、业务流程繁琐、并发处理能力不足等缺陷，导致患者排队时间延长、医务人员工作负担加重以及资源利用率低下。基于此，本研究以SpringBoot框架为技术基础，旨在构建一套具备高并发、高可用与易维护特性的医院预约挂号系统，以期通过技术创新提升医疗服务效率与质量。具体而言，本研究的主要目的包括：首先，通过模块化设计与微服务架构实现业务逻辑的解耦和灵活扩展，从而满足不同科室、不同规模医院对预约功能的多样化需求；其次，利用SpringBoot生态中的安全组件与分布式缓存技术，提升系统在高并发访问下的数据一致性与响应速度，显著缩短患者在线挂号所需时间；再次，通过引入基于角色的访问控制与细粒度日志审计机制，加强系统的安全性与可追溯性，为医院信息安全管理提供技术支撑；最后，结合实际医院运营数据进行性能评估与用户体验研究，验证系统在真实环境中的可行性与经济效益。通过上述目标的实现，本研究期望为国内外医疗机构提供一套可复制、可推广的预约挂号解决方案，并为后续基于微服务与云原生技术的医疗信息系统研发奠定理论与实践基础。

二、研究意义

在全球医疗资源分布不均、患者就诊需求日益增长的背景下，医院预约挂号系统的优化直接关系到医疗服务供给效率与患者满意度。通过构建基于SpringBoot的高并发、高可用预约平台，可显著降低患者现场排队时间，提升门诊资源利用率，从而缓解医院急诊与普通门诊之间的资源冲突。

此外，该系统采用微服务架构与模块化设计，能够实现业务逻辑的解耦与功能的快速迭代，满足不同科室、不同规模医院对挂号流程的定制化需求。其可扩展性与易维护性为医院信息系统的持续升级提供了技术保障，减少了系统停机时间与运维成本。

在数据治理层面，系统集成统一的日志审计与访问控制机制，为医疗机构的数据安全与合规监管提供了可靠支撑。通过对预约数据的实时采集与分析，可为医院管理层提供精准的资源调度决策依据，支持基于大数据的医疗服务优化与精准医疗发展。

从国家层面来看，该研究契合《健康中国2030》规划提出的数字化医疗建设目标，为构建智慧医疗生态系统奠定了技术基础。其可复制、可推广的实现方案为中小型医院提供了低成本、高性能的数字化升级路径，具有显著的社会经济价值。

综上所述，基于SpringBoot的医院预约挂号系统不仅在提升医疗服务质量与运营效率方面具有重要意义，而且在推动医疗信息化、保障数据安全与支持政策落地方面发挥着关键作用，为后续相关技术研究与行业实践提供了宝贵经验。

三、国内外研究现状

国内外在医院预约挂号系统研究领域已形成多条技术路线，主要聚焦于业务流程重构、系统性能优化与信息安全保障。首先，在业务流程重构方面，学者们通过引入服务导向架构（SOA）与微服务模式，对传统单体应用进行拆分，实现挂号、排队、支付等功能的独立部署，从而提升系统可维护性与灵活性；其次，在性能优化方面，研究者利用分布式缓存、消息队列与负载均衡技术，构建高并发处理框架，以满足峰值时段数千甚至数万并发请求的需求；再次，在信息安全保障方面，学术界提出基于角色访问控制（RBAC）与多因素身份验证的安全模型，并结合日志审计与异常检测机制，实现对患者隐私与系统操作的全程监控。

在技术实现层面，国内外已出现多种基于主流开源框架的解决方案，其中SpringBoot、Node.js、Python Flask等被广泛采用，以其轻量级、快速开发特性满足医疗信息系统对开发效率与可扩展性的双重需求。与此同时，容器化技术（Docker）与持续集成/持续交付（CI/CD）流程的引入，使得系统部署与升级周期显著缩短，降低了运维成本。

在数据治理方面，研究者通过构建统一的数据中台，实现预约、诊疗、药品等多源数据的整合与标准化，为后续的大数据分析与精准医疗提供基础。基于此，部分系统已实现对预约趋势的预测与资源调度优化算法，显著提升了门诊资源利用率。

在信息安全与合规性方面，学术界提出多层次安全防护模型，包括传输层加密、数据库加密、访问控制与审计日志等，并通过对比实验验证其在医疗数据泄露风险中的有效性。与此同时，针对隐私保护的技术研究也在不断深入，如差分隐私与同态加密技术被探索用于敏感数据的安全共享。

总体而言，国内外研究已形成以微服务架构为核心、以容器化与持续交付为支撑、以大数据与人工智能为赋能的全链路医院预约挂号系统框架。然而，仍存在诸如跨机构数据互联、实时异常检测与自适应调度等挑战，需要进一步在算法优化、系统集成与标准化治理方面开展深入研究。

四、预期达到目标及解决的关键问题

预期目标主要包括构建一套基于SpringBoot的医院预约挂号系统，能够在保证业务流程完整性的前提下实现高并发、高可用与易维护的技术架构；实现模块化与微服务化设计，使得挂号、排队、支付、信息查询等核心功能能够独立部署、快速迭代；通过引入分布式缓存与消息队列技术，提升系统在峰值时段的响应速度与吞吐量，显著降低患者在线挂号所需时间；实现细粒度的角色访问控制与多因素身份验证机制，保障患者个人信息与系统操作的安全性；通过统一数据中台实现预约、诊疗、药品等多源数据的标准化与集成，为后续大数据分析与精准医疗提供基础。

关键问题主要集中在以下几个方面：首先，高并发环境下的事务一致性与分布式锁机制，需要在微服务架构中设计可靠的数据同步与冲突解决策略；其次，系统的容错与自愈能力需要通过服务熔断、重试与限流等手段实现，以保证业务连续性；再次，跨机构数据互联与共享时的隐私保护与合规性问题，需要结合差分隐私或同态加密技术，兼顾数据利用价值与安全风险；此外，系统的运维与部署需要考虑容器化、持续集成/持续交付流程的成熟度，以降低运维成本并提升上线效率；最后，用户体验方面的可访问性与移动端适配也需在设计初期充分考虑，以满足不同终端用户的使用习惯。

五、研究内容

整体研究内容围绕基于SpringBoot的医院预约挂号系统的全链路技术实现展开，主要分为系统架构设计、核心业务模块实现、高并发与容错处理、信息安全与合规保障、数据治理与大数据应用以及运维与持续交付等六大模块。

在系统架构设计方面，首先采用微服务化思路，将挂号、排队、支付、信息查询等业务拆分为独立服务，并通过Spring Cloud提供的服务注册与发现机制实现动态路由；其次引入容器化技术，将各微服务打包为Docker镜像，利用Kubernetes实现弹性伸缩与自愈；再次通过API网关统一入口，完成请求鉴权、限流与日志收集。

核心业务模块实现方面，挂号服务采用分布式事务与乐观锁相结合的方式保证排队顺序与资源分配的一致性；排队服务利用Redis Sorted Set实现实时排队号生成与查询；支付服务集成多种支付渠道，并通过异步消息队列完成支付结果回调；信息查询服务提供科室、医生、时间段等多维度的预约信息检索。

高并发与容错处理主要围绕峰值时段的请求激增展开，首先利用Nginx+Spring Cloud Gateway实现请求层面的限流与熔断；其次在业务层引入Hystrix或Resilience4j实现服务降级与回退；再次通过Redis缓存热点数据与消息队列异步处理非核心任务，降低数据库压力；最后通过分布式锁（Redisson）解决并发预约冲突。

信息安全与合规保障重点在身份鉴权、数据加密与审计日志，采用JWT+OAuth2实现细粒度权限控制；在传输层使用TLS 1.3加密；对敏感字段采用AES-256对称加密存储；同时通过日志审计与异常检测实现对操作行为的实时监控，并满足医疗信息安全管理标准。

数据治理与大数据应用侧重于多源数据的统一抽象与标准化，构建数据中台将预约、诊疗、药品等业务表映射为统一的数据模型；通过Kafka实现业务事件的实时流式处理；在此基础上开发预测模型，对预约量进行时段预测与资源调度优化；此外，还提供基于差分隐私的统计分析接口，为医疗科研与决策支持提供安全数据。

运维与持续交付方面，构建CI/CD流水线，利用Git、Jenkins与Helm实现代码从提交到生产环境的全流程自动化；通过Prometheus+Grafana监控系统指标，设置告警阈值；采用ELK Stack进行日志聚合与分析；在灾备层面设计多活部署与数据同步方案，确保业务连续性。

综上所述，本研究通过系统化的技术架构、模块化的业务实现、高效的并发处理机制、完善的信息安全保障、统一的数据治理平台以及成熟的运维体系，致力于打造一套既满足现代医院运营需求，又具备可扩展性与可维护性的预约挂号系统。

六、需求分析

用户需求方面，系统的主要使用者包括患者、医务人员与医院管理人员。患者侧重于便捷、高效的挂号体验，期望能够通过手机或电脑快速查询科室、医生及空闲时间段，并在短时间内完成预约；同时希望系统提供实时排队信息、挂号结果推送以及在线支付功能，以减少现场排队与等候时间。医务人员需要一个统一的挂号管理界面，能够查看已预约患者名单、调整门诊资源、发布科室公告，并通过系统快速确认或取消预约；此外，医生还期望能在系统中查看患者既往病历与检查结果，以便提前做出诊疗准备。医院管理人员则关注整体运营效率与资源利用率，需通过系统获取预约量、医生排班、门诊收入等统计报表，并支持对挂号流程进行监控与优化；同时他们还需要确保系统安全合规，能够追踪每一次操作记录并满足隐私保护法规。综上所述，用户需求涵盖了易用性、实时性、安全性与可视化管理四大维度。

功能需求方面，系统需实现以下核心模块：挂号服务模块负责患者信息录入、科室医生选择及时间段确认，并通过分布式事务保证预约数据一致；排队管理模块利用Redis或数据库实现实时排队号生成与查询，支持多窗口并发操作；支付集成模块提供多种支付渠道（如在线支付、微信/支付宝等），并通过消息队列异步处理支付结果回调；通知推送模块支持短信、邮件及移动端推送，及时告知患者挂号成功、排队进度与医生变更等信息；数据分析与报表模块利用大数据技术对预约量、医生绩效、资源利用率等进行统计与预测，为医院决策提供依据；安全与权限管理模块采用JWT+OAuth2实现细粒度访问控制，并通过TLS加密传输、数据库字段加密及日志审计保障信息安全；最后，运维与持续交付模块通过容器化、CI/CD流水线实现快速迭代与高可用部署。上述功能需求共同构成了系统的完整业务链路，满足从患者挂号到医院运营管理的全流程需求。

七、可行性分析

经济可行性方面，系统的开发成本主要包括软件架构设计、前后端实现、数据库搭建与安全加固等技术投入，预计总投入在数十万元人民币左右；与此同时，系统上线后可通过减少患者现场排队时间、提升门诊资源利用率以及降低人工挂号错误率等方式，为医院带来显著的运营成本节约与收入提升。以往研究表明，在中型医院实施预约挂号系统后，门诊接待效率可提升20%至30%，而患者满意度指数亦随之上升，进而促使患者复诊率提高，形成良性循环。若将系统推广至多家医院，可实现规模化效益，通过共享技术与经验降低单个项目的边际成本，从而实现经济上的可持续发展。

社会可行性方面，患者在使用系统后能够享受更为便捷的挂号流程，减少排队等待时间，提高就医体验；医务人员则可通过系统精准掌握预约信息与排班安排，降低人工管理负担，提升工作效率；医院管理层能够获得实时数据分析与决策支持，进一步优化资源配置。与此同时，系统在数据隐私保护方面采用加密存储与多因素身份验证等措施，符合国家医疗信息安全法规，从而赢得公众信任。社会层面上，该系统的推广有助于缓解医疗资源短缺问题、提升基层医疗服务水平，并通过数字化手段促进健康管理与疾病预防，具有积极的公共卫生价值。

技术可行性方面，SpringBoot框架提供了成熟的微服务开发环境，能够快速搭建高可用、易扩展的系统；结合Spring Cloud生态实现服务治理、配置中心与熔断器等功能，可满足医院业务对高并发与容错的需求。数据库层面采用分布式关系型数据库或NoSQL解决方案，可实现事务一致性与实时查询；Redis缓存与Kafka消息队列进一步提升系统吞吐量与异步处理能力。系统安全方面，利用JWT+OAuth2实现细粒度权限控制，TLS 1.3加密传输以及数据库字段加密技术，能够满足医疗信息安全合规要求。鉴于医院现有信息系统多为老旧或定制化平台，系统可通过RESTful API与现有EHR、排班系统进行对接，实现数据互通与业务协同，从而降低集成难度。综上所述，技术层面具备成熟的实现路径与可扩展性，可在保证性能与安全的前提下完成项目交付。

八、功能分析

系统功能模块划分为七大核心子系统，分别为用户管理与身份鉴权、挂号预约、排队管理、支付与结算、通知推送、数据分析与报表以及系统运维与安全监控。每一模块均围绕业务流程的完整性与技术实现的可扩展性进行设计，以满足患者、医务人员及医院管理层的多维度需求。

用户管理与身份鉴权子系统负责患者、医生、护士及管理员等角色的注册、登录与权限分配，采用JWT+OAuth2实现细粒度访问控制；同时通过多因素身份验证与TLS 1.3加密传输保障数据安全；该子系统还提供密码重置、账号绑定与日志审计功能，以满足合规监管要求。

挂号预约子系统是核心业务模块，支持患者通过科室、医生及时间段筛选进行在线预约；系统利用分布式事务与乐观锁机制确保同一门诊时段的排队号唯一性；同时提供预约状态查询、改期与取消功能，并将预约信息同步至排队管理子系统。

排队管理子系统负责实时生成与维护挂号号牌，采用Redis Sorted Set实现高并发下的快速排序与查询；系统支持多窗口并发操作，能够根据医生排班表动态调整可用时间段；此外，该子系统还提供实时排队进度、预计等待时间以及患者自助改排功能。

支付与结算子系统集成多种在线支付渠道（如第三方支付平台、医保卡等），采用异步消息队列处理支付结果回调，确保挂号成功后及时完成费用结算；系统支持分期付款、优惠券使用及电子发票生成，并将交易记录写入安全审计日志。

通知推送子系统负责向患者与医务人员发送短信、邮件、移动端推送等多种渠道的实时通知，内容包括挂号成功提醒、排队进度更新、医生变更提示以及系统维护公告；该子系统通过消息队列实现异步发送，保障高并发时段的可靠性。

数据分析与报表子系统构建统一的数据中台，将预约、诊疗、支付等业务数据进行标准化存储与多维度聚合；通过实时流处理与批量分析生成门诊量、医生绩效、资源利用率等关键指标报表；系统还提供预测模型接口，支持预约量预测与资源调度优化。

系统运维与安全监控子系统集成Prometheus、Grafana及ELK Stack，实现对微服务实例的健康检查、性能指标监控与日志聚合；通过自动化脚本实现容器化部署的滚动升级与回滚；同时，系统提供权限审计、异常检测与安全告警功能，满足医疗信息安全管理规范。

综上所述，七大功能模块在业务逻辑上相互衔接、技术实现上相互支撑，共同构成一套完整、可扩展且安全可靠的医院预约挂号系统。

九、数据库设计

字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
---|---|---|---|---|---
id | 用户唯一标识 | 10 | bigint unsigned auto_increment | 主键 |
username | 登录名，唯一约束 | 50 | varchar(50) not null unique | 无主外键 |
password_hash | 密码哈希值 | 255 | varchar(255) not null | 无主外键 |
email | 邮箱地址，唯一约束 | 100 | varchar(100) unique | 无主外键 |
phone | 手机号码，唯一约束 | 20 | varchar(20) unique | 无主外键 |
role_id | 所属角色编号，关联role表id | 10 | bigint unsigned not null | 外键（role.id） |
created_at | 记录创建时间，格式yyyy-mm-dd hh:mm:ss | 19 | datetime not null default current_timestamp | 无主外键 |
updated_at | 记录更新时间，格式yyyy-mm-dd hh:mm:ss | 19 | datetime not null default current_timestamp on update current_timestamp | 无主外键 |

字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
---|---|---|---|---|---
id | 角色唯一标识 | 10 | bigint unsigned auto_increment | 主键 |
name | 角色名称，唯一约束 | 50 | varchar(50) not null unique | 无主外键 |
description | 角色描述，长度可变 | 255 | varchar(255) null | 无主外键 |

字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
---|---|---|---|---|---
id | 权限唯一标识 | 10 | bigint unsigned auto_increment | 主键 |
name | 权限名称，唯一约束 | 50 | varchar(50) not null unique | 无主外键 |
description | 权限描述，长度可变 | 255 | varchar(255) null | 无主外键 |

字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
---|---|---|---|---|---
user_id | 用户编号，关联user表id | 10 | bigint unsigned not null | 外键（user.id） |
role_id | 角色编号，关联role表id | 10 | bigint unsigned not null | 外键（role.id） |

字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
---|---|---|---|---|---
id | 科室唯一标识 | 10 | bigint unsigned auto_increment | 主键 |
name | 科室名称，唯一约束 | 100 | varchar(100) not null unique | 无主外键 |
location | 科室所在楼层或位置，长度可变 | 255 | varchar(255) null | 无主外键 |

字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
---|---|---|---|---|---
id | 医生唯一标识 | 10 | bigint unsigned auto_increment | 主键 |
user_id | 与用户表关联，存储登录信息编号，外键user.id | 10 | bigint unsigned not null | 外键（user.id） |
department_id | 所属科室编号，外键department.id | 10 | bigint unsigned not null | 外键（department.id） |
specialty | 专业领域，长度可变 | 100 | varchar(100) null | 无主外键 |
title | 职称，长度可变 | 50 | varchar(50) null | 无主外键 |

字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
---|---|---|---|---|---
id | 患者唯一标识 | 10 | bigint unsigned auto_increment | 主键 |
user_id | 与用户表关联，存储登录信息编号，外键user.id | 10 | bigint unsigned not null | 外键（user.id） |
gender | 性别，枚举值（M/F/Other） | 1 | char(1) not null | 无主外键 |
birth_date | 出生日期，格式yyyy-mm-dd | 10 | date null | 无主外键 |
address | 住址，长度可变 | 255 | varchar(255) null | 无主外键 |

字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
---|---|---|---|---|---
id | 挂号记录唯一标识 | 10 | bigint unsigned auto_increment | 主键 |
patient_id | 患者编号，外键patient.id | 10 | bigint unsigned not null | 外键（patient.id） |
doctor_id | 医生编号，外键doctor.id | 10 | bigint unsigned not null | 外键（doctor.id） |
appointment_time | 挂号时间，格式yyyy-mm-dd hh:mm:ss | 19 | datetime not null | 无主外键 |
status | 挂号状态（pending, confirmed, cancelled, completed） | 20 | varchar(20) not null default 'pending' | 无主外键 |
queue_position | 当前排队位置，整数，NULL表示未进入排队系统 | 10 | int unsigned null | 无主外键 |

字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
---|---|---|---|---|---
id | 支付记录唯一标识 | 10 | bigint unsigned auto_increment | 主键 |
appointment_id | 对应挂号记录编号，外键appointment.id | 10 | bigint unsigned not null | 外键（appointment.id） |
amount | 支付金额，精确到分，格式DECIMAL(10,2) | 12 | decimal(10,2) not null | 无主外键 |
payment_time | 支付时间，格式yyyy-mm-dd hh:mm:ss | 19 | datetime not null default current_timestamp | 无主外键 |
status | 支付状态（pending, completed, failed） | 20 | varchar(20) not null default 'pending' | 无主外键 |

字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
---|---|---|---|---|---
id | 通知记录唯一标识 | 10 | bigint unsigned auto_increment | 主键 |
user_id | 接收者用户编号，外键user.id | 10 | bigint unsigned not null | 外键（user.id） |
title | 通知标题，长度可变 | 100 | varchar(100) not null | 无主外键 |
content | 通知内容，长度可变，支持多行文本 | 65535 | text not null | 无主外键 |
sent_at | 发送时间，格式yyyy-mm-dd hh:mm:ss | 19 | datetime not null default current_timestamp | 无主外键 |
status | 发送状态（pending, sent, failed） | 20 | varchar(20) not null default 'pending' | 无主外键 |

字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
---|---|---|---|---|---
id | 报表数据唯一标识，用于存储聚合结果或缓存分析结果 | 10 | bigint unsigned auto_increment | 主键 |
report_type | 报表类型（appointment_count, doctor_performance, resource_utilization） | 50 | varchar(50) not null | 无主外键 |
generated_at | 生成时间，格式yyyy-mm-dd hh:mm:ss | 19 | datetime not null default current_timestamp | 无主外键 |
data_json | 报表数据，存储为JSON字符串，长度可变 | 65535 | text not null | 无主外键 |

上述表结构遵循第一范式与第二范式，避免重复数据与冗余字段；通过外键约束实现实体间的完整性；主键采用自增bigint保证唯一性；字段类型与大小根据业务实际需求设定，兼顾存储效率与可扩展性。

十、建表语句

CREATE TABLE user (
id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
username VARCHAR(50) NOT NULL UNIQUE,
password_hash VARCHAR(255) NOT NULL,
email VARCHAR(100) UNIQUE,
phone VARCHAR(20) UNIQUE,
role_id BIGINT UNSIGNED NOT NULL,
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (id),
CONSTRAINT fk_user_role FOREIGN KEY (role_id) REFERENCES role(id) ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE role (
id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
name VARCHAR(50) NOT NULL UNIQUE,
description VARCHAR(255),
PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE permission (
id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
name VARCHAR(50) NOT NULL UNIQUE,
description VARCHAR(255),
PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE user_role (
user_id BIGINT UNSIGNED NOT NULL,
role_id BIGINT UNSIGNED NOT NULL,
PRIMARY KEY (user_id, role_id),
CONSTRAINT fk_user_role_user FOREIGN KEY (user_id) REFERENCES user(id) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT fk_user_role_role FOREIGN KEY (role_id) REFERENCES role(id) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE department (
id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
name VARCHAR(100) NOT NULL UNIQUE,
location VARCHAR(255),
PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE doctor (
id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
user_id BIGINT UNSIGNED NOT NULL,
department_id BIGINT UNSIGNED NOT NULL,
specialty VARCHAR(100),
title VARCHAR(50),
PRIMARY KEY (id),
CONSTRAINT fk_doctor_user FOREIGN KEY (user_id) REFERENCES user(id) ON DELETE RESTRICT ON UPDATE CASCADE,
CONSTRAINT fk_doctor_department FOREIGN KEY (department_id) REFERENCES department(id) ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE patient (
id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
user_id BIGINT UNSIGNED NOT NULL,
gender CHAR(1) NOT NULL,
birth_date DATE,
address VARCHAR(255),
PRIMARY KEY (id),
CONSTRAINT fk_patient_user FOREIGN KEY (user_id) REFERENCES user(id) ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE appointment (
id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
patient_id BIGINT UNSIGNED NOT NULL,
doctor_id BIGINT UNSIGNED NOT NULL,
appointment_time DATETIME NOT NULL,
status VARCHAR(20) NOT NULL DEFAULT 'pending',
queue_position INT UNSIGNED,
PRIMARY KEY (id),
INDEX idx_appointment_time (appointment_time),
INDEX idx_appointment_status (status),
CONSTRAINT fk_appointment_patient FOREIGN KEY (patient_id) REFERENCES patient(id) ON DELETE RESTRICT ON UPDATE CASCADE,
CONSTRAINT fk_appointment_doctor FOREIGN KEY (doctor_id) REFERENCES doctor(id) ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE payment (
id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
appointment_id BIGINT UNSIGNED NOT NULL,
amount DECIMAL(10,2) NOT NULL,
payment_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
status VARCHAR(20) NOT NULL DEFAULT 'pending',
PRIMARY KEY (id),
INDEX idx_payment_status (status),
CONSTRAINT fk_payment_appointment FOREIGN KEY (appointment_id) REFERENCES appointment(id) ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE notification (
id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
user_id BIGINT UNSIGNED NOT NULL,
title VARCHAR(100) NOT NULL,
content TEXT NOT NULL,
sent_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
status VARCHAR(20) NOT NULL DEFAULT 'pending',
PRIMARY KEY (id),
INDEX idx_notification_status (status),
CONSTRAINT fk_notification_user FOREIGN KEY (user_id) REFERENCES user(id) ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE report (
id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
report_type VARCHAR(50) NOT NULL,
generated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
data_json TEXT NOT NULL,
PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

文章下方名片联系我即可~大家点赞、收藏、关注、评论啦 、查看下方👇🏻获取联系方式👇🏻