项目实训（二）｜中医智能诊疗系统数据库模块设计与开发落地
项目实训（二）｜中医智能诊疗系统数据库模块设计与开发落地
项目开发日志 | 阶段二：中医智能诊疗系统数据库层设计与功能实现
中医智能诊疗系统开发日志：数据库层设计与实现——从需求到落地的技术思考
前言
本阶段是中医智能诊疗系统的数据底座建设阶段，核心目标是搭建稳定、可扩展、可协作的数据库模块。本篇从需求理解、架构选择、设计思路、工程实践四个角度，记录我在本阶段的技术理解与真实开发进度。
后期根据项目整体业务定位，数据库结构已完成迭代升级，新增用户、患者档案、体质记录、养生食疗、药箱管理等表，完善了医生 - 用户 - 会话 - 诊疗全流程关联，适配后续 RAG、舌诊、食疗安全检查等功能。
一、阶段目标与整体规划
在进入具体编码前，我先明确了本阶段必须完成的核心任务：
- 完成 PostgreSQL + pgvector 环境部署，为后续向量检索预留能力
- 围绕诊疗对话业务，设计会话、消息、症状记录相关表结构
- 基于 SQLAlchemy 完成 ORM 模型封装，实现面向对象的数据操作
- 封装标准化 CRUD，为上层接口提供稳定依赖
- 完成数据库连接管理、脚本规范化，并按团队 Git 规范提交
整个过程遵循先设计、再编码、后验证、再提交的工程化思路，确保每一步都可追溯、可复用、可协作。
二、数据库选型背后的业务思考
在选型时，我没有直接选用轻量级数据库，而是根据项目长期演进路线做出判断：
- 项目未来需要接入中医知识库，需要向量存储
- 团队多人协作，需要支持多用户、高并发
- 诊疗数据具有强业务关系，需要事务与外键约束
- 生产环境要求稳定、可备份、可扩展
PostgreSQL 配合 pgvector 扩展，恰好满足关系型数据与向量数据混合存储的需求。这一决策让项目从一开始就具备长期迭代能力，而不只是满足当前最小可用功能。
三、表结构设计：从业务流程到数据模型
在设计表结构时，我先梳理了诊疗对话全流程：
用户注册 → 完善档案 → 体质识别 → 开启会话 → 多轮交互 → 症状提取 → 诊疗/养生方案 → 记录存档 → 历史对比。
基于项目最新业务定位，我设计了完整的结构化数据表体系，覆盖用户、诊疗、舌诊、养生、RAG知识库、食疗安全等全场景：
users 用户表
存储医生、用户的基础信息，包括用户名、密码、姓名、角色等。user_profiles 用户档案表
记录用户详细信息：性别、年龄、身高、体重、过敏史、病史、电话等，为个性化诊疗提供依据。constitution_records 体质记录表
存储用户体质问卷答案、体质得分、AI判定结果、解释与建议，支持中医体质辨识。sessions 会话表
作为诊疗/舌诊的上下文载体，关联用户与档案，支持两种会话类型，存储已提取症状。messages 消息表
记录用户与AI助手的多轮对话内容，保证对话历史可追溯、可复现。diagnoses 诊疗记录表
存储传统诊疗的症状、诊断结果、处方、推荐方案。wellness_records 养生记录表
核心用于食疗养生，包含症状、状态分析、食疗方案、穴位推荐、生活建议、安全警告等。medication_box 个人药箱表
支持用户记录常用药物、剂量、用途、服用时间，便于长期健康管理。agent_outputs 智能体输出表
记录大模型与RAG检索的原始输出，用于幻觉控制、过程回溯与效果验证。comparison_records 对比记录表
支持多次诊疗/体质结果对比，便于观察健康变化趋势。
在设计细节上，我坚持几个原则：
- 所有表统一使用 UUID 主键，带时区时间戳，保证分布式环境下数据一致性
- 使用外键约束与级联删除，保证关联数据不冗余、不异常
- 支持 JSONB / TEXT[ ] 等高级类型，适配大模型输出与复杂结构存储
- 表结构通过 SQL 脚本统一管理，支持团队快速初始化、重复执行
这套设计不仅覆盖当前业务，更提前为RAG检索、舌诊模块、食疗安全检查、大模型幻觉控制、历史对比等功能预留了完整的数据结构支撑。
四、代码架构设计：分层思想与可维护性
在编码阶段，我采用清晰的三层数据架构：
- 连接层：负责数据库连接、会话管理、连接池配置
- 模型层：将表结构映射为 ORM 类，实现类型安全与对象化操作
- CRUD 层：封装通用数据操作，对外提供稳定接口，避免重复 SQL
这种架构的优势非常明显：
- 逻辑解耦，便于团队分工维护
- 业务变化时只需修改对应层，不影响整体
- 代码可读性高，符合现代后端工程规范
在实现过程中，我深刻体会到：好的架构不是写最复杂的代码，而是写最容易被别人读懂、维护、扩展的代码。
后期数据库升级后，我也同步适配了新表的 CRUD 操作，保持架构统一、调用方式一致。
五、功能验证与进度成果
本阶段最终完成并验证通过的内容包括：
- 数据库环境正常，pgvector 扩展启用成功
- 全套业务表创建完成，关系正确，约束生效，支持用户、档案、会话、诊疗、养生、药箱全流程
- 数据库连接稳定，支持并发访问
- 会话创建、消息存储、症状记录等功能全部可用
- 初始化脚本可重复执行，适配团队开发流程
- 代码按规范提交至远程 dev 分支
所有功能均通过真实数据读写测试，模块可直接接入下一阶段的接口开发。
六、技术理解与收获
通过本阶段开发，我对数据库工程化实践有了更真实的理解：
- 数据库设计本质是业务逻辑的持久化映射，必须先懂业务再建表
- 好的数据结构能大幅降低上层代码复杂度
- 连接管理、权限控制、脚本规范是团队协作的基础
- 代码规范、结构清晰、注释合理比单纯实现功能更重要
本阶段完成的不仅是功能，更是整个项目的数据底座与开发规范。