企业官网建设流程全解析

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

一、研究目的

在当前数字化转型的背景下，家政服务行业正面临从传统人工服务向信息化、网络化模式转变的迫切需求。该行业的服务流程复杂，涉及客户需求采集、服务人员排班、费用结算以及售后评价等多环节，而传统模式在信息共享、资源调度和质量监管方面存在明显瓶颈。微信小程序凭借其无需下载安装、易于推广、与社交生态深度融合的特性，已成为移动互联网用户获取服务的重要入口；而SpringBoot作为一种高效的后端框架，能够快速构建微服务架构，提供可扩展、高可用的业务支持。将两者结合，可在保证系统灵活性的同时，实现前后端分离、模块化开发，为家政服务行业提供一套完整的数字化解决方案。

本研究旨在通过基于SpringBoot与微信小程序的技术架构，设计并实现一套面向终端用户和服务商的家政服务预约平台。具体目标包括：①构建可扩展的后端服务体系，实现订单管理、用户管理、支付接口、评价系统等核心业务功能；②开发高性能、高可用的微信小程序前端，提供便捷的预约流程、实时客服互动以及个性化推荐；③通过微服务拆分与容器化部署，保障系统在高并发访问下的稳定性和弹性扩展能力；④引入数据分析与机器学习模块，对用户行为进行建模，为精准营销和资源优化提供决策支持。研究过程中将采用敏捷开发与持续集成的实践方法，确保需求快速迭代与质量可控。

在技术实现层面，本研究计划实现前后端解耦、接口统一、数据一致性保障等关键技术点，并通过OAuth2.0与微信开放平台的安全认证机制，提升用户信息安全与隐私保护水平。系统性能评估将采用压力测试、负载均衡与缓存优化等手段，确保在峰值流量下响应时间不超过200毫秒。为验证平台的业务价值，将对比传统服务模式在订单完成率、客户满意度、运营成本等指标上的差异，并通过用户访谈与问卷调查收集定性与定量数据，形成完整的评估报告。

本研究的创新点体现在技术集成与业务模式双重突破上。首先，利用SpringBoot的自动化配置与模块化特性，实现后端服务快速迭代；其次，通过微信小程序的生态优势，降低用户获取成本并提升活跃度；再次，系统中引入智能匹配与推荐算法，提升资源配置效率和服务质量。研究成果将为家政服务行业提供可复制、可推广的数字化平台架构，为相关企业在激烈的市场竞争中赢得技术与运营优势；同时，也为学术界在移动互联网与企业服务数字化交叉领域提供新的研究案例与实践经验。

二、研究意义

在信息技术迅猛发展的时代背景下，传统家政服务行业亟需通过数字化手段实现业务流程的标准化、透明化与高效化，以满足日益多样化的消费需求和提升服务质量。基于SpringBoot与微信小程序的技术架构能够有效整合前后端资源，提供统一、可扩展的服务接口，从而降低系统维护成本并提升开发效率。该平台通过实现订单管理、用户身份认证、在线支付以及评价反馈等核心功能，能够在保障数据安全与隐私的前提下，为用户提供便捷的预约体验，并为服务商提供精准的资源调度与绩效评估工具。研究成果不仅为家政行业搭建了可复制、可推广的数字化运营模式，也为相关领域如共享经济、移动支付和云计算等交叉学科提供了实践案例与技术参考。通过引入机器学习算法进行用户行为分析与服务匹配，本研究进一步提升了资源利用率与客户满意度，为行业实现从粗放式经营向精细化管理的转型奠定了理论基础和技术支撑。综上所述，该研究在推动家政服务行业数字化升级、优化产业链条、提升社会治理水平以及促进经济高质量发展等方面具有重要的学术价值与现实意义。

三、国内外研究现状

在全球范围内，家政服务平台的研究主要聚焦于信息化与网络化的融合、服务质量评估以及智能匹配算法。学术界普遍采用微服务架构与云计算技术，以实现业务模块的高可用与弹性扩展；同时，研究者也在探索基于大数据与机器学习的需求预测模型，以提升资源调度效率。针对移动端应用，现有文献强调用户体验设计、支付安全以及多渠道接入的重要性，并提出了统一身份认证与权限管理的解决方案。在算法层面，协同过滤、内容推荐与深度学习相结合的智能匹配方法已在多项实验中取得显著提升，能够在短时间内为用户匹配到最合适的服务人员。

国内研究方面，学者们对家政服务平台的系统架构展开了深入探讨。多数研究倾向于采用基于Java的后端框架，结合RESTful API与前端单页应用实现模块化开发；其中，SpringBoot被视为主流技术之一，其自动化配置与插件生态使得快速搭建微服务成为可能。针对移动端，微信小程序因其无需安装、易于推广的特性而成为研究热点。国内多篇论文通过对小程序界面交互、支付流程以及后台数据同步的细致分析，总结出一套适用于本土家政市场的开发规范与性能优化策略。与此同时，研究者也关注平台运营中的数据安全与隐私保护，提出基于加密传输、权限分级与日志审计的安全模型，并在实验环境中验证了其可行性。

在服务匹配与推荐方面，国内外均已开展多项实验。国外研究多侧重于利用深度学习模型对用户行为进行特征提取，并通过强化学习实现动态调度；国内则更注重基于规则与协同过滤的混合模型，以适应数据稀疏与业务场景复杂的特点。实验结果表明，结合用户历史评价、服务人员技能标签与实时需求信息的多维度匹配模型能够显著提升订单完成率与客户满意度。除此之外，学术界还关注平台运营中的价格机制设计与激励策略，提出了基于双边市场理论的动态定价模型，并在模拟实验中验证了其对供需平衡的积极作用。

在技术实现层面，国内外研究普遍采用容器化与持续集成技术，以提升系统的部署效率与可维护性。微服务拆分后，服务之间通过轻量级通信协议实现协作；同时，使用消息队列与事件驱动架构解决了高并发下的数据一致性问题。针对微信小程序的后端接口设计，研究者提出了统一的鉴权中间件与接口网关方案，以降低前后端耦合度并提升安全性。通过对比实验，发现该方案在高峰期仍能保持低延迟与高吞吐量。

总体而言，国内外在家政服务平台的研究已形成多条技术路线：一是基于微服务与云原生技术构建弹性后端；二是利用微信小程序实现低门槛前端接入；三是通过大数据与机器学习提升服务匹配效率；四是强化安全与隐私保护以赢得用户信任。上述研究成果为本项目提供了丰富的技术参考与实践经验，尤其在平台架构设计、前后端解耦、安全鉴权以及智能匹配算法方面具有重要借鉴价值。

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

本研究的预期目标在于构建一套基于SpringBoot与微信小程序的家政服务预约平台，涵盖前后端完整功能实现、系统性能优化以及业务流程再造等方面。首先，平台将实现订单管理、用户身份认证、在线支付、评价反馈与客服互动等核心业务模块，并通过微服务架构实现业务解耦与弹性扩展；其次，在前端层面，微信小程序将提供简洁直观的预约流程、实时位置跟踪与服务人员信息展示，满足移动端用户的使用习惯；再次，通过引入大数据分析与机器学习技术，对用户行为进行建模，为精准匹配与个性化推荐提供决策支持；最后，系统将采用容器化部署与持续集成流程，确保在高并发访问下保持低延迟与高可用性。为实现上述目标，本研究将重点解决以下关键问题：一是如何在SpringBoot框架下实现模块化的后端服务，并通过统一的API网关保障接口安全与调用效率；二是如何设计微信小程序的前端交互逻辑，使得用户在预约、支付与评价过程中体验流畅且信息透明；三是如何构建高效的数据同步机制，确保前后端数据一致性，特别是在订单状态变更、支付结果回调与评价上传等关键节点；四是如何利用机器学习算法对服务人员技能标签、用户历史偏好与实时需求进行多维度匹配，以提升匹配准确率与资源利用率；五是如何在保证系统性能的前提下，实现安全的支付集成与身份认证，防止信息泄露与恶意攻击；六是如何通过监控与日志分析机制，及时发现并解决系统瓶颈，保障平台在高峰期仍保持稳定运行。为此，本研究将采用敏捷开发与持续集成的工作模式，结合单元测试、压力测试与安全审计等手段，在迭代中不断验证与优化设计方案。通过上述目标与关键问题的系统化解决，本项目旨在为家政服务行业提供一套可复制、可推广的数字化运营平台，同时为学术界在移动互联网与企业服务数字化交叉领域提供新的研究案例与技术路径。

五、研究内容

本研究首先在需求分析阶段，采用功能点与业务流程图相结合的方法，对家政服务行业的核心业务进行细化拆解，形成用户预约、服务人员排班、支付结算、评价反馈与客服互动等七大功能模块，并通过用例图与序列图明确各模块之间的交互关系。随后，在系统架构设计阶段，基于SpringBoot框架搭建微服务化后端，采用Spring Cloud技术实现服务治理、配置中心与路由网关，确保各业务子系统能够独立部署、水平扩展且易于维护；前端则选用微信小程序技术栈，通过微信开放平台的身份认证与支付接口，实现用户身份验证、订单创建与支付流程的无缝衔接。两端通过RESTful API进行数据交互，所有接口均采用HTTPS加密传输，并在网关层统一实现鉴权与限流策略，以保障系统安全与高可用。

在数据层面，研究设计了分布式数据库架构，主数据库采用关系型数据库存储核心业务数据，如用户信息、订单详情与评价记录；辅之以NoSQL数据库缓存热点数据，如服务人员实时状态与订单状态变更，利用Redis实现高速缓存与消息队列机制，确保在高并发访问下仍能保持低延迟响应。为实现订单与服务人员的精准匹配，系统引入基于协同过滤与深度学习的推荐算法，将用户历史行为、服务人员技能标签与实时需求进行多维特征融合，并通过在线学习模型持续优化匹配精度。算法模块采用Python Flask微服务部署，并通过gRPC接口与后端Java服务进行高效调用。

安全与合规性方面，研究在身份认证层使用OAuth2.0协议与微信小程序的授权码流程相结合，确保用户信息在传输与存储过程中的机密性；支付环节则集成微信支付SDK，并通过签名校验与回调验证机制防止伪造交易；所有敏感数据在数据库层采用AES加密存储，并通过访问控制列表实现细粒度权限管理。为满足监管要求，系统提供日志审计功能，记录关键操作与异常事件，并支持对账与合规报表的自动生成。

性能评估与持续交付方面，本研究采用JMeter进行压力测试，模拟高并发用户请求，并通过Grafana+Prometheus监控系统指标，如CPU使用率、内存占用、数据库查询延迟与消息队列长度，实时发现瓶颈。基于测试结果，系统通过代码优化、索引调整与缓存策略迭代提升性能；同时采用Docker容器化部署与Kubernetes编排，实现灰度发布与滚动升级，确保业务连续性。最终，通过用户体验测试与业务指标对比验证平台在订单完成率、平均等待时间与客户满意度等方面的显著提升，为家政服务行业提供可复制、可推广的数字化运营解决方案。

六、需求分析

用户需求方面，平台的目标用户主要包括城市中高收入家庭、单身白领以及需要长期家政服务的老年人群体；这些用户普遍对服务质量、价格透明度与预约便捷性有较高期望。首先，用户期望能够在移动端快速完成注册与身份验证，且不需要繁琐的资料提交，微信小程序的授权登录功能能够满足此需求；其次，用户希望通过直观的界面浏览多种家政服务类型，如保洁、月嫂、育儿嫂等，并能查看服务人员的资质证书、过往评价与实时可用性，以便做出明智选择；再次，用户对预约流程的顺畅度有严格要求，期望能够在几步之内完成时间选择、服务内容确认与支付操作，并在订单生成后获得即时的订单状态推送；此外，用户对安全与隐私高度重视，希望平台能够保障个人信息不被泄露，同时对支付过程提供多重加密与风险提示；最后，用户期望在出现服务中断或质量问题时能够及时获得客服支持，且评价系统能够真实反映服务体验，以便后续决策。综上所述，用户需求聚焦于便捷性、透明度、安全性与可靠的售后保障。

功能需求方面，平台需实现完整的订单管理模块，包括订单创建、状态跟踪、取消与退款处理，并通过后台数据库实时同步订单信息；用户注册与登录模块应支持微信授权登录、手机号验证以及密码重置功能，并在后端进行身份鉴权与权限校验；服务人员管理模块需提供资质上传、技能标签设置、可用时间表维护以及绩效统计，以便平台能够根据需求进行精准匹配；调度与派单模块应集成智能匹配算法，基于用户位置、服务类型与服务人员可用性自动生成最佳派单方案，并支持人工干预与调整；支付集成模块需对接微信支付SDK，完成订单金额计算、支付回调验证以及账务记录，同时支持多种支付方式与分期付款选项；评价与评分模块应允许用户在服务结束后提交文字评论与星级评分，并对服务人员进行综合绩效评估；客服与通知模块需实现实时消息推送、订单提醒、促销活动发布以及在线客服聊天功能，以提升用户体验；数据安全与合规模块必须包括数据加密存储、访问权限控制、日志审计与合规报表生成，确保平台满足相关法律法规的要求。上述功能需求共同构成了平台的核心业务支撑体系。

七、可行性分析

经济可行性方面，平台的初始投入主要集中在软件研发、服务器租赁与第三方支付接口对接等方面，预计总成本可控制在数十万元人民币以内；通过采用开源框架与云服务的按需计费模式，可显著降低硬件采购与运维费用；收入来源主要包括订单佣金、增值服务订阅以及广告推广，基于行业平均佣金率与用户活跃度预测，平台在上线后六个月内即可实现盈亏平衡；此外，平台的可扩展性为未来多业务线的融合提供了成本优势，如引入家居维修或宠物护理等相关服务，可进一步提升客单价与复购率，从而增强长期盈利能力。社会可行性方面，家政服务作为传统劳动密集型行业，在数字化转型后可实现劳动力资源的精准配置与高效调度，平台通过智能匹配算法减少空闲时间，提高服务人员收入稳定性；同时，平台为消费者提供透明的价格与评价体系，提升消费信任度，符合当前社会对服务质量与安全的重视；在监管层面，平台遵循个人信息保护法与电子商务法的相关规定，通过加密传输与权限分级实现数据安全合规；此外，平台通过提供在线客服与投诉处理机制，有助于维护消费者权益，减少纠纷发生，从而获得社会认可与支持。技术可行性方面，后端采用成熟的SpringBoot框架，可快速构建微服务化架构，并通过Spring Cloud实现服务治理与配置中心，确保系统在高并发访问下保持稳定；前端采用微信小程序技术，利用已有的生态优势降低用户获取成本，并通过微信开放平台提供的身份验证与支付SDK实现安全便捷的登录与支付流程；数据库层面结合关系型数据库与Redis缓存，实现事务一致性与高速读写；安全层面通过OAuth2.0授权、HTTPS加密传输以及日志审计机制，满足行业对数据安全与合规性的严格要求；整体架构具备容器化部署与持续集成的能力，可实现快速迭代与灰度发布，充分体现技术实现的可行性。

八、功能分析

系统功能模块可分为用户管理模块、服务目录与信息展示模块、预约与订单管理模块、支付与结算模块、智能调度与派单模块、评价与客服支持模块以及后台运营管理模块。用户管理模块负责实现微信小程序授权登录、手机号绑定、个人信息维护及权限校验，所有敏感数据均采用加密存储，并通过多因素验证提升安全性；服务目录与信息展示模块提供家政服务类型分类、服务人员资质证书展示、技能标签与过往评价查询，支持多维度筛选与搜索功能，以满足用户对服务质量的透明需求；预约与订单管理模块实现订单创建、时间段选择、服务内容确认以及订单状态跟踪，系统通过消息推送实时告知用户订单进度，并支持取消与退款操作；支付与结算模块集成微信支付SDK完成订单金额计算、支付回调验证及账务记录，支持分期付款与优惠券抵扣，并在后台生成财务报表；智能调度与派单模块基于用户位置、服务类型、服务人员可用性与历史匹配评分自动生成最佳派单方案，系统通过消息队列将派单信息推送给对应服务人员，并支持人工干预与调整；评价与客服支持模块允许用户在服务完成后提交文字评论与星级评分，系统对评价进行审核后更新服务人员绩效，并通过在线客服聊天、FAQ与工单系统为用户提供售后支持；后台运营管理模块为管理员提供用户数据分析、订单统计、财务报表生成、服务人员绩效评估与调度监控等功能，支持多级权限管理与日志审计，确保平台运营的透明性与合规性。每个模块之间通过RESTful API进行解耦式调用，并在网关层统一实现鉴权、限流与监控，保证系统整体的高可用与安全。

九、数据库设计

字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
---|---|---|---|---|---
user_id | 用户编号 | 10 | int(11) unsigned auto_increment | 主键 | 系统内部唯一标识用户
wechat_openid | 微信开放平台唯一标识符 | 50 | varchar(50) | | 用于微信小程序登录鉴权
name | 用户姓名或昵称 | 50 | varchar(50) | |
phone | 联系电话 | 20 | varchar(20) | |
email | 邮箱地址（可选） | 100 | varchar(100) | |
created_at | 创建时间戳 | - | datetime | |
updated_at | 更新时间戳 | - | datetime |
provider_id (服务商表) |
---|---|---|---|---|---
provider_id | 服务商编号 | 10 | int(11) unsigned auto_increment | 主键 |
user_id (服务商表) | 所属用户编号 | 10 | int(11) unsigned | 外键，引用User(user_id) |
name (服务商表) | 服务商名称或店铺名 | 100 | varchar(100) |
certification_cert_no | 资质证书编号（可选） | 50 | varchar(50) |
avatar_url | 头像链接（可选） | 200 | varchar(200) |
rating (服务商表) | 综合评分，取值0.00~5.00 | - | decimal(3,2) |
status (服务商表) | 状态，取值active、inactive | - | enum('active','inactive') |
category_id (服务类别表) |
---|---|---|---|---|---
category_id | 类别编号 | 10 | int(11) unsigned auto_increment | 主键 |
name (服务类别表) | 类别名称，如保洁、月嫂等 | 50 | varchar(50) |
service_id (服务项目表) |
---|---|---|---|---|---
service_id | 服务项目编号 | 10 | int(11) unsigned auto_increment | 主键 |
provider_id (服务项目表) | 所属服务商编号 | 10 | int(11) unsigned | 外键，引用ServiceProvider(provider_id) |
category_id (服务项目表) | 所属类别编号 | 10 | int(11) unsigned | 外键，引用ServiceCategory(category_id) |
name (服务项目表) | 服务名称，如“深度清洁” | 100 | varchar(100) |
description | 服务描述（可选） | - | text |
price (服务项目表) | 单价，单位元 | - | decimal(10,2) |
duration_minutes (服务项目表) | 预计时长，单位分钟 | 5 | int(11) |
order_id (订单表) |
---|---|---|---|---|---
order_id | 订单编号 | 10 | int(11) unsigned auto_increment | 主键 |
user_id (订单表) | 下单用户编号 | 10 | int(11) unsigned | 外键，引用User(user_id) |
service_id (订单表) | 选定服务项目编号 | 10 | int(11) unsigned | 外键，引用ServiceItem(service_id) |
provider_id (订单表) | 指派服务商编号（可在确认后更新） | 10 | int(11) unsigned | 外键，引用ServiceProvider(provider_id) |
scheduled_time | 预约时间戳 | - | datetime |
status (订单表) | 状态，取值pending、confirmed、in_progress、completed、cancelled | - | enum('pending','confirmed','in_progress','completed','cancelled') |
created_at (订单表) | 订单创建时间戳 | - | datetime |
payment_id (支付表) |
---|---|---|---|---|---
payment_id | 支付编号 | 10 | int(11) unsigned auto_increment | 主键 |
order_id (支付表) | 关联订单编号 | 10 | int(11) unsigned | 外键，引用Order(order_id) |
amount (支付表) | 支付金额，单位元 | - | decimal(10,2) |
payment_time (支付表) | 支付时间戳 | - | datetime |
payment_method (支付表) | 付款方式，取值wechat、alipay | - | enum('wechat','alipay') |
status (支付表) | 支付状态，取值paid、failed | - | enum('paid','failed') |
eval_id (评价表) |
---|---|---|---|---|---
eval_id | 评价编号 | 10 | int(11) unsigned auto_increment | 主键 |
order_id (评价表) | 关联订单编号 | 10 | int(11) unsigned | 外键，引用Order(order_id) |
user_id (评价表) | 评价用户编号（下单人） | 10 | int(11) unsigned | 外键，引用User(user_id) |
provider_id (评价表) | 被评价服务商编号 | 10 | int(11) unsigned | 外键，引用ServiceProvider(provider_id) |
rating (评价表) | 星级评分，取值1~5 | - | int(1) |
comment (评价表) | 文字评论（可选） | - | text |
created_at (评价表) | 评价时间戳 | - | datetime |
message_id (消息表) |
---|---|---|---|---|---
message_id | 消息编号 | 10 | int(11) unsigned auto_increment | 主键 |
sender_user_id (消息表) | 发送者用户编号 | 10 | int(11) unsigned | 外键，引用User(user_id) |
receiver_user_id (消息表) | 接收者用户编号（可为服务商或客服） | 10 | int(11) unsigned | 外键，引用User(user_id) |
content (消息表) | 消息内容（文字、图片链接等） | - | text |
sent_at (消息表) | 发送时间戳 | - | datetime |
address_id (地址表) |
---|---|---|---|---|---
address_id | 地址编号 | 10 | int(11) unsigned auto_increment | 主键 |
user_id (地址表) | 所属用户编号 | 10 | int(11) unsigned | 外键，引用User(user_id) |
address_line (地址表) | 详细地址（街道、门牌号等） | 200 | varchar(200) |
city (地址表) | 城市名称 | 50 | varchar(50) |
province (地址表) | 省份或直辖市名称 | 50 | varchar(50) |
zip_code (地址表) | 邮政编码（可选） | 10 | varchar(10) |

以上表结构遵循第一范式与第二范式，主键唯一标识每条记录，外键约束保证数据完整性；字段长度与类型均根据业务需求与常见数据特征设定，确保系统在存储、查询与维护方面的高效性。

十、建表语句

CREATE TABLE user (
user_id INT UNSIGNED NOT NULL AUTO_INCREMENT,
wechat_openid VARCHAR(50) NOT NULL,
name VARCHAR(50) DEFAULT NULL,
phone VARCHAR(20) DEFAULT NULL,
email VARCHAR(100) DEFAULT NULL,
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (user_id),
UNIQUE KEY uk_wechat_openid (wechat_openid)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE service_provider (
provider_id INT UNSIGNED NOT NULL AUTO_INCREMENT,
user_id INT UNSIGNED NOT NULL,
name VARCHAR(100) NOT NULL,
certification_cert_no VARCHAR(50) DEFAULT NULL,
avatar_url VARCHAR(200) DEFAULT NULL,
rating DECIMAL(3,2) DEFAULT '0.00',
status ENUM('active','inactive') NOT NULL DEFAULT 'active',
PRIMARY KEY (provider_id),
KEY idx_provider_user_id (user_id),
CONSTRAINT fk_provider_user FOREIGN KEY (user_id) REFERENCES user(user_id) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE service_category (
category_id INT UNSIGNED NOT NULL AUTO_INCREMENT,
name VARCHAR(50) NOT NULL,
PRIMARY KEY (category_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE service_item (
service_id INT UNSIGNED NOT NULL AUTO_INCREMENT,
provider_id INT UNSIGNED NOT NULL,
category_id INT UNSIGNED NOT NULL,
name VARCHAR(100) NOT NULL,
description TEXT DEFAULT NULL,
price DECIMAL(10,2) NOT NULL DEFAULT '0.00',
duration_minutes INT(11) NOT NULL DEFAULT '0',
PRIMARY KEY (service_id),
KEY idx_service_provider_id (provider_id),
KEY idx_service_category_id (category_id),
CONSTRAINT fk_service_provider FOREIGN KEY (provider_id) REFERENCES service_provider(provider_id) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT fk_service_category FOREIGN KEY (category_id) REFERENCES service_category(category_id) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE order (
order_id INT UNSIGNED NOT NULL AUTO_INCREMENT,
user_id INT UNSIGNED NOT NULL,
service_id INT UNSIGNED NOT NULL,
provider_id INT UNSIGNED DEFAULT NULL,
scheduled_time DATETIME NOT NULL,
status ENUM('pending','confirmed','in_progress','completed','cancelled') NOT NULL DEFAULT 'pending',
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (order_id),
KEY idx_order_user_id (user_id),
KEY idx_order_service_id (service_id),
KEY idx_order_provider_id (provider_id),
CONSTRAINT fk_order_user FOREIGN KEY (user_id) REFERENCES user(user_id) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT fk_order_service_item FOREIGN KEY (service_id) REFERENCES service_item(service_id) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT fk_order_provider FOREIGN KEY (provider_id) REFERENCES service_provider(provider_id) ON DELETE SET NULL ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE payment (
payment_id INT UNSIGNED NOT NULL AUTO_INCREMENT,
order_id INT UNSIGNED NOT NULL,
amount DECIMAL(10,2) NOT NULL DEFAULT '0.00',
payment_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
payment_method ENUM('wechat','alipay') NOT NULL,
status ENUM('paid','failed') NOT NULL DEFAULT 'paid',
PRIMARY KEY (payment_id),
KEY idx_payment_order_id (order_id),
CONSTRAINT fk_payment_order FOREIGN KEY (order_id) REFERENCES order(order_id) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE evaluation (
eval_id INT UNSIGNED NOT NULL AUTO_INCREMENT,
order_id INT UNSIGNED NOT NULL,
user_id INT UNSIGNED NOT NULL,
provider_id INT UNSIGNED NOT NULL,
rating TINYINT(1) NOT NULL CHECK (rating BETWEEN 1 AND 5),
comment TEXT DEFAULT NULL,
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (eval_id),
KEY idx_eval_order_id (order_id),
KEY idx_eval_user_id (user_id),
KEY idx_eval_provider_id (provider_id),
CONSTRAINT fk_eval_order FOREIGN KEY (order_id) REFERENCES order(order_id) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT fk_eval_user FOREIGN KEY (user_id) REFERENCES user(user_id) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT fk_eval_provider FOREIGN KEY (provider_id) REFERENCES service_provider(provider_id) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE message (
message_id INT UNSIGNED NOT NULL AUTO_INCREMENT,
sender_user_id INT UNSIGNED NOT NULL,
receiver_user_id INT UNSIGNED NOT NULL,
content TEXT NOT NULL,
sent_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (message_id),
KEY idx_msg_sender_user_id (sender_user_id),
KEY idx_msg_receiver_user_id (receiver_user_id),
CONSTRAINT fk_msg_sender_user FOREIGN KEY (sender_user_id) REFERENCES user(user_id) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT fk_msg_receiver_user FOREIGN KEY (receiver_user_id) REFERENCES user(user_id) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE address (
address_id INT UNSIGNED NOT NULL AUTO_INCREMENT,
user_id INT UNSIGNED NOT NULL,
address_line VARCHAR(200) NOT NULL,
city VARCHAR(50) NOT NULL,
province VARCHAR(50) NOT NULL,
zip_code VARCHAR(10) DEFAULT NULL,
PRIMARY KEY (address_id),
KEY idx_address_user_id (user_id),
CONSTRAINT fk_address_user FOREIGN KEY (user_id) REFERENCES user(user_id) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

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