网硕互联帮助中心博主介绍：✌ 专注于VUE,小程序，安卓，Java,python,物联网专业，有18年开发经验，长年从事毕业指导，项目实战✌选取一个适合的毕业设计题目很重要。✌关注✌私信我✌具体的问题，我会尽力帮助你。
一、研究目的
本研究旨在构建一套基于SpringBoot与Vue技术栈的牙科诊所预约平台，以解决传统预约方式中存在的效率低下、信息不对称以及患者体验欠佳等问题。通过采用SpringBoot框架，后端服务能够实现高并发请求处理、事务管理以及安全认证，满足诊所业务流程的严谨性与可靠性；而Vue前端则提供响应式界面与组件化开发模式，使用户交互更加直观、流畅，从而提升患者满意度与系统易用性。研究重点在于设计一套完整的系统架构，涵盖预约查询、医生排班、患者档案管理、支付结算以及数据统计分析等核心功能，并通过模块化实现代码可维护性与可扩展性。
本项目的技术目标包括：①实现预约模块，支持多种预约方式（线上预约、电话预约）并实时更新医生排班表；②构建患者信息管理系统，集成电子病历、治疗记录与历史账单，实现数据的安全存储与快速检索；③开发支付接口，支持多种支付渠道（支付宝、微信支付）并保证交易安全；④提供后台管理面板，支持诊所管理员对医生排班、预约统计及系统设置进行全局控制；⑤实现移动端适配，确保在各类终端设备上均能获得一致的用户体验。通过上述功能的集成，本研究期望为牙科诊所提供一套高效、可靠且易于维护的预约解决方案。
研究方法将采用需求分析、系统设计、原型实现与性能评估相结合的方式。首先，收集并整理牙科诊所在预约流程中遇到的痛点与需求，形成详细的功能规格说明；随后，依据SpringBoot与Vue生态进行技术选型与架构设计，制定模块划分与接口规范；接下来，通过敏捷迭代快速实现核心功能，并利用单元测试、集成测试以及压力测试验证系统稳定性；最后，对比传统预约方式与本平台在预约成功率、系统响应时间、用户满意度等指标上的差异，进行定量评估。通过系统化的研究流程，本项目旨在为牙科诊所提供一套可落地、可持续发展的数字化预约平台，并为相关领域的技术创新与实践提供参考与借鉴。
二、研究意义
本研究通过整合SpringBoot与Vue技术栈，构建牙科诊所预约平台，旨在实现预约流程的数字化与智能化，从而显著提升诊所运营效率和患者体验。该平台能够实时同步医生排班信息，避免因排班冲突导致的重复预约或空闲资源浪费，进而降低运营成本并提高资源利用率。通过引入电子病历与治疗记录管理模块，患者既可在预约时上传既往病史，又能在诊疗后即时获取电子账单与复诊提醒，显著提升医疗信息透明度与患者对医疗服务的信任度。平台支持多种支付渠道与在线结算功能，减少现金交易环节，为患者提供更便捷的支付体验，同时为诊所提供精准的财务数据分析。系统采用微服务架构与RESTful API设计，保证了后端业务逻辑的高可扩展性与易维护性，能够满足未来功能迭代与业务规模扩张的需求。通过移动端适配与响应式前端实现，患者可在不同终端上无缝访问预约服务，提升用户黏性并扩大诊所服务覆盖面。研究成果将为传统牙科诊所提供一套完整、可落地的数字化解决方案，推动医疗行业信息化升级与服务模式创新。进一步而言，该平台的技术架构与模块化设计具有可复制性，可推广至其他医疗门诊或慢性病管理等领域，为我国医疗信息系统建设提供参考与借鉴。综上所述，本研究不仅在技术层面实现了前后端协同与高并发处理，更在业务层面提升了患者满意度、优化了资源配置、降低了运营成本，并为医疗行业数字化转型提供了可持续发展的范式。
三、国内外研究现状
国内外在医疗预约系统领域的研究已形成若干主流方向，涵盖技术架构优化、用户体验提升、智能调度与数据分析等方面。首先，在技术架构层面，国外学者普遍采用微服务与容器化技术，利用Docker、Kubernetes等平台实现系统的弹性伸缩与高可用性；国内研究则侧重于基于SpringBoot的模块化设计，通过统一的接口网关与服务注册中心实现业务解耦。其次，移动端应用已成为用户接入的主要渠道。国外研究多聚焦于跨平台框架（如React Native、Flutter）与原生App的混合开发，以提升性能与兼容性；国内则以Vue.js为核心，结合Element UI或Ant Design实现响应式界面，强调组件复用与快速迭代。再次，智能调度是当前热点之一。国外已将机器学习算法（如协同过滤、强化学习）应用于医生排班与预约冲突预测，显著降低空闲率；国内研究多采用规则引擎与优化算法（如遗传算法、蚁群算法）实现排班优化，兼顾医生偏好与患者需求。第四，数据安全与隐私保护是两国共同关注点。国外通过OAuth2.0、JWT等标准实现身份认证，并采用GDPR合规框架；国内则结合国家网络安全法与个人信息保护法，采用加密存储、访问控制等技术手段保障数据安全。第五，系统集成与互操作性方面，国外研究强调FHIR标准的应用，实现电子病历与预约系统的无缝对接；国内研究则侧重于接口标准化与API网关管理，以实现多业务系统间的数据共享。总体来看，国外在技术创新与标准化方面更为成熟，而国内在快速迭代与本土化需求满足方面具有优势。通过对比分析，可见现有研究已在提高预约效率、优化资源配置、提升用户体验等方面取得显著成果，但仍存在系统集成复杂、智能调度精度不足以及跨平台兼容性差等挑战。针对牙科诊所这一细分领域，结合国内外研究经验，可进一步探索基于SpringBoot与Vue的高性能预约平台，以满足专业化医疗服务的特定需求。
四、预期达到目标及解决的关键问题
本研究的预期目标主要体现在系统功能完整性、性能可靠性、用户体验优化以及数据安全合规四个维度。首先，系统功能完整性目标是实现预约查询、医生排班管理、患者档案维护、在线支付及后台统计分析等核心模块，并通过模块化设计保证代码可维护性与可扩展性；其次，性能可靠性目标是确保在高并发访问场景下，系统响应时间不超过200毫秒，事务处理成功率达到99.9%；再次，用户体验优化目标是通过响应式前端与人机交互设计，使患者在移动端完成预约、支付与提醒的平均操作时长控制在30秒以内；最后，数据安全合规目标是采用加密存储、访问控制与审计日志等技术手段，满足国家个人信息保护法与医疗数据安全规范的要求。
在实现上述目标过程中，研究将面临若干关键问题。首要问题是前后端解耦与接口一致性。Vue前端需要通过RESTful API与SpringBoot后端进行高效通信，而接口版本管理、错误处理与数据格式统一将直接影响系统的可维护性与扩展性；其次，实时排班冲突检测与解决是核心技术挑战之一。系统需在患者预约请求到达时即时查询医生可用时段，并通过算法优化排班表，避免重复预约或资源浪费；再次，高并发下的数据一致性保障也是关键难点。在多节点部署与分布式事务管理环境中，如何保证患者信息、预约记录与支付状态的一致性，需要采用分布式锁、消息队列或两阶段提交等机制；此外，系统的安全合规也存在技术与管理双重挑战。除了技术层面的加密与权限控制，还需建立完善的审计日志、数据脱敏与访问监控流程，以满足监管要求。
为解决上述关键问题，本研究将采用微服务架构与容器化部署，利用SpringCloud进行服务治理与熔断处理；在排班调度方面，将结合遗传算法与强化学习模型，实现医生排班的自适应优化；在高并发一致性保障方面，将引入分布式事务管理框架与消息中间件，确保数据最终一致性；在安全合规方面，将采用OAuth2.0授权框架、JWT令牌以及AES加密存储，配合日志审计与权限细粒度控制，构建完整的安全体系。通过上述技术路线的实施，本研究期望构建一套高性能、易维护、用户友好且合规安全的牙科诊所预约平台，为医疗行业数字化转型提供可复制、可推广的技术与实践经验。
五、研究内容
本研究以构建一套基于SpringBoot与Vue技术栈的牙科诊所预约平台为核心目标，整体内容围绕系统架构设计、核心功能实现、算法优化与性能评估四大模块展开。首先，在系统架构设计方面，采用微服务化理念将后端拆分为用户服务、预约服务、排班服务、支付服务与统计分析服务等子系统，并通过SpringCloud实现服务治理与统一网关；前端则采用Vue3框架结合Composition API与Vue Router实现单页面应用，利用Element Plus构建响应式组件库，以满足移动端与桌面端的兼容需求。其次，核心功能实现层面包含预约查询、医生排班管理、患者档案维护、在线支付及后台管理等关键模块，其中预约查询模块通过GraphQL接口提供灵活的数据检索；排班管理模块采用遗传算法对医生可用时段进行优化，以兼顾工作负荷与患者需求；支付服务则集成第三方支付SDK，并通过异步消息队列保证交易状态的最终一致性。随后，在算法优化层面，针对预约冲突检测与资源调度，研究将引入强化学习模型对排班策略进行在线学习，从而在多变的临床环境中实现自适应调度；同时，在数据安全与隐私保护方面，将采用AES-256加密存储患者敏感信息，并通过JWT与OAuth2.0实现细粒度访问控制，确保系统满足国家个人信息保护法与医疗数据安全规范。最后，性能评估与系统验证环节将采用负载测试工具JMeter模拟高并发请求，并通过分布式追踪（如OpenTelemetry）监控服务链路延迟；同时，利用单元测试、集成测试与端到端自动化测试保证代码质量与功能完整性。通过上述研究内容的系统推进，本项目旨在为牙科诊所提供一套高效、可靠且安全的预约解决方案，并为医疗信息系统的数字化转型提供可复制、可推广的技术架构与实践经验。
六、需求分析
用户需求方面，系统首先需满足患者端的便捷性与信息透明度。患者期望能够在移动设备上随时查询诊所医生排班信息、可预约时段以及诊疗项目费用，并通过一键预约完成挂号流程；同时，患者需要接收实时短信或推送通知，提醒预约时间、医生变更或支付成功情况；此外，患者对个人健康档案的安全与隐私保护提出高标准要求，期望平台能够提供加密存储、访问权限管理以及数据导出功能。医生端需求则侧重于排班管理与患者沟通。医生希望通过平台快速查看自身排班表、接受或拒绝预约请求，并在诊疗过程中随时更新病历记录；医生还需要系统提供病例检索、药品库存查询及费用结算等辅助工具，以提升临床工作效率。诊所管理员则关注整体运营与合规管理。管理员需要通过后台管理面板实时监控预约量、医生利用率与财务报表，能够对排班策略进行调整、设置优惠活动以及生成业务分析报告；同时，管理员必须确保系统满足国家医疗信息安全标准，对用户数据进行审计与权限分配。综上所述，平台需兼顾患者、医生与管理员三方需求，在便捷性、效率、安全性与合规性方面实现平衡。
功能需求方面，系统需实现完整的预约管理模块。该模块包括预约查询、预约提交、预约取消及冲突检测等子功能；在查询时，系统应支持按医生、时间段或诊疗项目过滤，并返回实时可用时段；在提交时，系统需验证患者身份、检查医生可用性并生成唯一预约编号；在取消时，应自动释放时间槽并通知相关方。排班管理模块需提供医生排班表的可视化编辑与自动优化功能，支持手动调整与算法推荐，并能够同步更新至预约查询接口。患者档案管理模块需实现电子病历存储、历史诊疗记录检索、药品过敏信息标注及健康报告导出等功能；同时，模块应支持多语言文本与图像附件上传。支付集成模块需兼容主流支付渠道，提供订单生成、支付回调处理与退款机制，并通过加密通道保障交易安全。后台统计分析模块需聚合预约量、医生利用率、收入分布等指标，生成可视化报表并支持导出为Excel或PDF。最后，系统安全与权限管理模块需实现OAuth2.0授权、JWT令牌验证、细粒度角色权限控制以及日志审计，以满足医疗数据保护法规。
七、可行性分析
经济可行性方面，本研究所采用的SpringBoot与Vue技术栈均为开源框架，能够显著降低软件开发与维护成本；在硬件层面，平台可部署于云服务器或本地服务器，且支持弹性伸缩，从而实现按需付费模式；从收益角度来看，牙科诊所通过在线预约系统可减少人工接待与排队时间，提高门诊利用率，进而提升收入；此外，平台还可通过数据分析为诊所提供精准营销与服务优化建议，进一步扩大业务规模。项目初期投入主要包括软件开发、系统集成与培训费用，预计在三至六个月内即可实现收支平衡；长期来看，随着用户基数的扩大与功能迭代，平台可通过订阅服务、增值功能或数据分析服务实现持续盈利。综上所述，从成本收益比与市场需求角度看，该项目具备良好的经济可行性。
社会可行性方面，随着移动互联网普及与患者对医疗服务便捷性的诉求提升，线上预约系统已成为医疗行业发展的趋势；本平台通过提供随时随地预约、实时排班查询与支付结算功能，能够显著提升患者就医体验与满意度；同时，系统对患者个人健康信息采用加密存储与细粒度权限控制，符合国家个人信息保护法的要求，能够获得公众信任；然而，平台推广仍需克服部分患者对线上医疗服务安全性的顾虑，需要通过宣传教育与透明化运营来提升社会接受度。总体而言，该项目在满足患者需求、提升医疗服务效率与保障数据安全方面具备较高的社会可行性。
技术可行性方面，SpringBoot提供了成熟的微服务框架与丰富的生态插件，能够快速构建高并发、容错性强的后端服务；Vue3结合Composition API与TypeScript，可实现组件化、响应式前端开发，提升代码可维护性与开发效率；在数据层面，采用MySQL或PostgreSQL等关系型数据库，并配合Redis缓存，可满足实时查询与高并发写入需求；系统安全方面，通过OAuth2.0授权、JWT令牌以及AES-256加密实现身份验证与数据保护，符合医疗信息安全标准；在可扩展性方面，容器化部署与Kubernetes编排可实现水平扩容，满足业务增长。技术层面已具备完整的架构设计与实现路径，故本项目具备充分的技术可行性。
八、功能分析
系统功能模块按照业务流程与角色职责划分为六大核心模块，分别为用户服务模块、医生服务模块、管理员服务模块、预约管理模块、排班与调度模块以及支付与财务模块。用户服务模块主要负责患者端的身份认证、个人信息维护、健康档案上传与下载以及诊疗项目查询，支持患者通过手机号或邮箱完成注册登录，并可在移动端查看医生排班表、预约时段及费用信息；同时，该模块提供预约提交、取消与修改接口，并在后台触发短信或推送通知提醒患者预约状态。医生服务模块则实现医生身份认证、专业资质上传、个人排班表管理以及诊疗记录录入功能，医生可在专属界面查看已接收的预约请求并进行确认或拒绝，同时可在诊疗过程中实时记录病历与药品使用情况，并生成电子处方。管理员服务模块为诊所管理层提供后台权限控制、用户角色分配、系统配置管理以及安全审计日志查询功能，管理员可通过图形化界面对所有业务数据进行监控与调整。预约管理模块是系统的核心，负责预约请求的接收、冲突检测、时间槽分配与确认流程，支持按医生、时间段或诊疗项目进行筛选，并在后台生成唯一预约编号；该模块同时提供预约历史查询与统计分析接口。排班与调度模块实现医生排班表的可视化编辑与自动优化功能，采用遗传算法或强化学习模型对可用时段进行预测与调整，以最大化医生利用率并兼顾患者需求；该模块还支持跨科室资源共享与突发事件调度。支付与财务模块集成主流支付渠道，提供订单生成、支付回调处理、退款机制以及账单生成服务，所有交易数据均采用加密存储并通过分布式事务保证最终一致性；该模块同时提供收入报表、结算对账及税务申报接口。综上所述，系统通过上述模块的协同工作，实现从患者预约到医生诊疗、从后台管理到财务结算的完整闭环，为牙科诊所提供高效、安全、可扩展的数字化服务平台。
九、数据库设计
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
—|—|—|—|—|—
user_id | 用户编号 | 36 | CHAR(36) | 主键 | UUID
username | 用户名 | 50 | VARCHAR(50) | |
password_hash | 密码哈希值 | 64 | CHAR(64) | |
email | 邮箱地址 | 100 | VARCHAR(100) | |
phone_number | 手机号码 | 15 | VARCHAR(15) | |
role_id | 用户角色编号（患者/医生/管理员）|36|CHAR(36)|外键（role.role_id）|
created_at | 创建时间 | – | DATETIME | |
updated_at | 更新时间 | – | DATETIME | |
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
—|—|—|—|—|—
role_id | 角色编号（患者/医生/管理员）|36|CHAR(36)|主键|
role_name | 角色名称 | 20 | VARCHAR(20) | |
description | 描述信息 | 200 | VARCHAR(200) | |
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
—|—|—|—|—|—
doctor_id | 医生编号 | 36 | CHAR(36) | 主键 |
user_id | 对应用户编号（医生）|36|CHAR(36)|外键（user.user_id）|
specialty | 专业科目 | 50 | VARCHAR(50) |
license_number | 医师执业证号 | 30 | VARCHAR(30) |
profile_image_url | 头像链接 | 200 | VARCHAR(200) |
created_at | 创建时间 | – | DATETIME |
updated_at | 更新时间 | – | DATETIME |
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
—|—|—|—|—|—
schedule_id | 排班编号 | 36 | CHAR(36) | 主键 |
doctor_id | 医生编号 | 36 | CHAR(36) | 外键（doctor.doctor_id）|
date | 日期（YYYY-MM-DD）|10|DATE||
start_time | 开始时间（HH:MM）|5|TIME||
end_time | 结束时间（HH:MM）|5|TIME||
status | 状态（可预约/已占用/已取消）|10|VARCHAR(10)||
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
—|—|—|—|—|—
appointment_id | 预约编号 | 36 | CHAR(36) | 主键 |
user_id | 患者编号 | 36 | CHAR(36) | 外键（user.user_id）|
doctor_id | 医生编号 | 36 | CHAR(36) | 外键（doctor.doctor_id）|
schedule_id | 排班编号（对应时间槽）|36|CHAR(36)|外键（schedule.schedule_id）|
appointment_time | 预约时间戳 | – | DATETIME |
status | 状态（待确认/已确认/已完成/已取消）|10|VARCHAR(10)||
created_at | 创建时间 | – | DATETIME |
updated_at | 更新时间 | – | DATETIME |
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
—|—|—|—|—|—
payment_id | 支付编号 | 36 | CHAR(36) | 主键 |
appointment_id | 预约编号（关联）|36|CHAR(36)|外键（appointment.appointment_id）|
amount | 金额（元） | – | DECIMAL(10,2)||
currency | 货币类型 | 3 | CHAR(3)||
payment_method | 支付方式（支付宝/微信/银行卡）|10|VARCHAR(10)||
status | 状态（已支付/已退款/失败）|10|VARCHAR(10)||
transaction_id | 第三方交易号 | 64 | VARCHAR(64)||
created_at | 创建时间 | – | DATETIME |
updated_at | 更新时间 | – | DATETIME |
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
—|—|—|—|—|—
record_id | 病历编号 | 36 | CHAR(36) | 主键 |
user_id | 患者编号 | 36 | CHAR(36) | 外键（user.user_id）|
doctor_id | 医生编号 | 36 | CHAR(36) | 外键（doctor.doctor_id）|
appointment_id | 预约编号（关联病历）|36|CHAR(36)|外键（appointment.appointment_id）|
diagnosis | 诊断结果 | 500 | TEXT||
treatment_plan | 治疗方案 | 500 | TEXT||
prescription | 处方药品信息 | 500 | TEXT||
created_at | 创建时间 | – | DATETIME |
updated_at | 更新时间 | – | DATETIME |
上述表结构遵循第一范式（每列为原子值）、第二范式（非主属性完全依赖主键）与第三范式（无传递依赖），实现数据的规范化与完整性约束。
十、建表语句
CREATE DATABASE IF NOT EXISTS dental_appointment CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
USE dental_appointment;
— 角色表
CREATE TABLE role (
role_id CHAR(36) NOT NULL,
role_name VARCHAR(20) NOT NULL,
description VARCHAR(200),
PRIMARY KEY (role_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
— 用户表
CREATE TABLE user (
user_id CHAR(36) NOT NULL,
username VARCHAR(50) NOT NULL,
password_hash CHAR(64) NOT NULL,
email VARCHAR(100),
phone_number VARCHAR(15),
role_id CHAR(36) NOT NULL,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (user_id),
UNIQUE KEY uq_user_username (username),
UNIQUE KEY uq_user_email (email),
UNIQUE KEY uq_user_phone (phone_number),
CONSTRAINT fk_user_role FOREIGN KEY (role_id) REFERENCES role(role_id) ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
— 医生信息表
CREATE TABLE doctor (
doctor_id CHAR(36) NOT NULL,
user_id CHAR(36) NOT NULL,
specialty VARCHAR(50),
license_number VARCHAR(30),
profile_image_url VARCHAR(200),
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (doctor_id),
UNIQUE KEY uq_doctor_license (license_number),
CONSTRAINT fk_doctor_user FOREIGN KEY (user_id) REFERENCES user(user_id) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
— 排班表
CREATE TABLE schedule (
schedule_id CHAR(36) NOT NULL,
doctor_id CHAR(36) NOT NULL,
date DATE NOT NULL,
start_time TIME NOT NULL,
end_time TIME NOT NULL,
status VARCHAR(10) DEFAULT 'available',
PRIMARY KEY (schedule_id),
UNIQUE KEY uq_schedule_doctor_date_time (doctor_id, date, start_time, end_time),
CONSTRAINT fk_schedule_doctor FOREIGN KEY (doctor_id) REFERENCES doctor(doctor_id) ON DELETE CASCADE ON UPDATE CASCADE,
INDEX idx_schedule_date (date)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
— 预约表
CREATE TABLE appointment (
appointment_id CHAR(36) NOT NULL,
user_id CHAR(36) NOT NULL,
doctor_id CHAR(36) NOT NULL,
schedule_id CHAR(36) NOT NULL,
appointment_time DATETIME NOT NULL,
status VARCHAR(10) DEFAULT 'pending',
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (appointment_id),
UNIQUE KEY uq_appointment_user_schedule (user_id, schedule_id),
CONSTRAINT fk_appointment_user FOREIGN KEY (user_id) REFERENCES user(user_id) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT fk_appointment_doctor FOREIGN KEY (doctor_id) REFERENCES doctor(doctor_id) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT fk_appointment_schedule FOREIGN KEY (schedule_id) REFERENCES schedule(schedule_id) ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
— 支付表
CREATE TABLE payment (
payment_id CHAR(36) NOT NULL,
appointment_id CHAR(36) NOT NULL,
amount DECIMAL(10,2) NOT NULL,
currency CHAR(3) DEFAULT 'CNY',
payment_method VARCHAR(10),
status VARCHAR(10) DEFAULT 'pending',
transaction_id VARCHAR(64),
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (payment_id),
UNIQUE KEY uq_payment_appointment (appointment_id),
CONSTRAINT fk_payment_appointment FOREIGN KEY (appointment_id) REFERENCES appointment(appointment_id) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
— 病历表
CREATE TABLE medical_record (
record_id CHAR(36) NOT NULL,
user_id CHAR(36) NOT NULL,
doctor_id CHAR(36) NOT NULL,
appointment_id CHAR(36) NOT NULL,
diagnosis TEXT,
treatment_plan TEXT,
prescription TEXT,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (record_id),
CONSTRAINT fk_record_user FOREIGN KEY (user_id) REFERENCES user(user_id) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT fk_record_doctor FOREIGN KEY (doctor_id) REFERENCES doctor(doctor_id) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT fk_record_appointment FOREIGN KEY (appointment_id) REFERENCES appointment(appointment_id) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
— 索引优化
CREATE INDEX idx_user_role ON user(role_id);
CREATE INDEX idx_doctor_user ON doctor(user_id);
CREATE INDEX idx_schedule_doctor ON schedule(doctor_id);
CREATE INDEX idx_appointment_user ON appointment(user_id);
CREATE INDEX idx_appointment_doctor ON appointment(doctor_id);
CREATE INDEX idx_payment_appointment ON payment(appointment_id);
文章下方名片联系我即可~大家点赞、收藏、关注、评论啦 、查看下方👇🏻获取联系方式👇🏻
评论前必须登录！
注册