项目实训（二）｜中医智能诊疗系统数据库模块设计与开发落地

项目开发日志 | 阶段二：中医智能诊疗系统数据库层设计与功能实现

---

中医智能诊疗系统开发日志：数据库层设计与实现——从需求到落地的技术思考

前言

本阶段是中医智能诊疗系统的数据底座建设阶段，核心目标是搭建稳定、可扩展、可协作的数据库模块。本篇从需求理解、架构选择、设计思路、工程实践四个角度，记录我在本阶段的技术理解与真实开发进度。

后期根据项目整体业务定位，数据库结构已完成迭代升级，新增用户、患者档案、体质记录、养生食疗、药箱管理等表，完善了医生 - 用户 - 会话 - 诊疗全流程关联，适配后续 RAG、舌诊、食疗安全检查等功能。

---

一、阶段目标与整体规划

在进入具体编码前，我先明确了本阶段必须完成的核心任务：

1. 完成 PostgreSQL + pgvector 环境部署，为后续向量检索预留能力
2. 围绕诊疗对话业务，设计会话、消息、症状记录相关表结构
3. 基于 SQLAlchemy 完成 ORM 模型封装，实现面向对象的数据操作
4. 封装标准化 CRUD，为上层接口提供稳定依赖
5. 完成数据库连接管理、脚本规范化，并按团队 Git 规范提交

整个过程遵循先设计、再编码、后验证、再提交的工程化思路，确保每一步都可追溯、可复用、可协作。

---

二、数据库选型背后的业务思考

在选型时，我没有直接选用轻量级数据库，而是根据项目长期演进路线做出判断：

• 项目未来需要接入中医知识库，需要向量存储
• 团队多人协作，需要支持多用户、高并发
• 诊疗数据具有强业务关系，需要事务与外键约束
• 生产环境要求稳定、可备份、可扩展

PostgreSQL 配合 pgvector 扩展，恰好满足关系型数据与向量数据混合存储的需求。这一决策让项目从一开始就具备长期迭代能力，而不只是满足当前最小可用功能。

---

三、表结构设计：从业务流程到数据模型

在设计表结构时，我先梳理了诊疗对话全流程：
用户注册 → 完善档案 → 体质识别 → 开启会话 → 多轮交互 → 症状提取 → 诊疗/养生方案 → 记录存档 → 历史对比。

基于项目最新业务定位，我设计了完整的结构化数据表体系，覆盖用户、诊疗、舌诊、养生、RAG知识库、食疗安全等全场景：

1. users 用户表
   存储医生、用户的基础信息，包括用户名、密码、姓名、角色等。

2. user_profiles 用户档案表
   记录用户详细信息：性别、年龄、身高、体重、过敏史、病史、电话等，为个性化诊疗提供依据。

3. constitution_records 体质记录表
   存储用户体质问卷答案、体质得分、AI判定结果、解释与建议，支持中医体质辨识。

4. sessions 会话表
   作为诊疗/舌诊的上下文载体，关联用户与档案，支持两种会话类型，存储已提取症状。

5. messages 消息表
   记录用户与AI助手的多轮对话内容，保证对话历史可追溯、可复现。

6. diagnoses 诊疗记录表
   存储传统诊疗的症状、诊断结果、处方、推荐方案。

7. wellness_records 养生记录表
   核心用于食疗养生，包含症状、状态分析、食疗方案、穴位推荐、生活建议、安全警告等。

8. medication_box 个人药箱表
   支持用户记录常用药物、剂量、用途、服用时间，便于长期健康管理。

9. agent_outputs 智能体输出表
   记录大模型与RAG检索的原始输出，用于幻觉控制、过程回溯与效果验证。

10. comparison_records 对比记录表
    支持多次诊疗/体质结果对比，便于观察健康变化趋势。

在设计细节上，我坚持几个原则：

• 所有表统一使用 UUID 主键，带时区时间戳，保证分布式环境下数据一致性
• 使用外键约束与级联删除，保证关联数据不冗余、不异常
• 支持 JSONB / TEXT[ ] 等高级类型，适配大模型输出与复杂结构存储
• 表结构通过 SQL 脚本统一管理，支持团队快速初始化、重复执行

这套设计不仅覆盖当前业务，更提前为RAG检索、舌诊模块、食疗安全检查、大模型幻觉控制、历史对比等功能预留了完整的数据结构支撑。

---

四、代码架构设计：分层思想与可维护性

在编码阶段，我采用清晰的三层数据架构：

1. 连接层：负责数据库连接、会话管理、连接池配置
2. 模型层：将表结构映射为 ORM 类，实现类型安全与对象化操作
3. CRUD 层：封装通用数据操作，对外提供稳定接口，避免重复 SQL

这种架构的优势非常明显：

• 逻辑解耦，便于团队分工维护
• 业务变化时只需修改对应层，不影响整体
• 代码可读性高，符合现代后端工程规范

在实现过程中，我深刻体会到：好的架构不是写最复杂的代码，而是写最容易被别人读懂、维护、扩展的代码。

后期数据库升级后，我也同步适配了新表的 CRUD 操作，保持架构统一、调用方式一致。

---

五、功能验证与进度成果

本阶段最终完成并验证通过的内容包括：

• 数据库环境正常，pgvector 扩展启用成功
• 全套业务表创建完成，关系正确，约束生效，支持用户、档案、会话、诊疗、养生、药箱全流程
• 数据库连接稳定，支持并发访问
• 会话创建、消息存储、症状记录等功能全部可用
• 初始化脚本可重复执行，适配团队开发流程
• 代码按规范提交至远程 dev 分支

所有功能均通过真实数据读写测试，模块可直接接入下一阶段的接口开发。

---

六、技术理解与收获

通过本阶段开发，我对数据库工程化实践有了更真实的理解：

• 数据库设计本质是业务逻辑的持久化映射，必须先懂业务再建表
• 好的数据结构能大幅降低上层代码复杂度
• 连接管理、权限控制、脚本规范是团队协作的基础
• 代码规范、结构清晰、注释合理比单纯实现功能更重要

本阶段完成的不仅是功能，更是整个项目的数据底座与开发规范。

---