17370845950

个人健康管理系统需分离敏感与非敏感用户信息，health_records表用DATETIME(3)存毫秒级时间戳并以JSON存指标值，用药记录必须关联标准药品编码，禁用宽表预聚合而应通过视图或定时任务生成aggregates。

个人健康管理系统不是电商或社交类系统，数据关系相对简单，但对时间精度、单位一致性、隐私字段保护和历史追溯要求高。直接上“用户-订单-商品”式设计会踩坑。

用户主表必须分离敏感信息

身份证号、手机号、紧急联系人等属于高敏字段，不能和基础资料（如昵称、头像）混在一张 users 表里。否则备份、日志、测试库脱敏成本极高。

• user_profiles 存昵称、性别、出生日期、头像URL、身高体重（当前值）、常用运动偏好等非

  

  敏感字段
• user_privacy 存 id_card_hash（SHA256 加盐哈希）、phone_encrypted（AES-256加密）、emergency_contact（同样加密），且该表仅限特定服务账号查询
• 两表通过 user_id 关联，禁止在应用层做 JOIN 拼装完整用户对象——由后端服务分别查、分别解密

健康指标记录要带时间戳+设备来源+校验状态

血压、血糖、心率这些数据不是“最新一条”就够用，临床分析依赖采样时间、设备型号、是否手动录入。MySQL 的 TIMESTAMP 类型不够，得用 DATETIME(3) 保留毫秒级精度。

CREATE TABLE health_records (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  user_id BIGINT NOT NULL,
  metric_type ENUM('blood_pressure', 'blood_glucose', 'heart_rate', 'spo2') NOT NULL,
  value_json JSON NOT NULL,
  recorded_at DATETIME(3) NOT NULL,
  device_id VARCHAR(64) NULL,
  is_manual TINYINT(1) DEFAULT 0,
  status ENUM('raw', 'validated', 'rejected') DEFAULT 'raw',
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  INDEX idx_user_time (user_id, recorded_at),
  INDEX idx_time_type (recorded_at, metric_type)
);

说明：value_json 存具体值（如 {"systolic":120,"diastolic":80}），避免为每种指标建单独字段导致表膨胀；status 字段用于标记数据是否经医生复核，导出报表时可过滤掉 rejected 数据。

用药记录必须关联药品标准编码，不能存药品名称字符串

用户手动输入“阿司匹林肠溶片”可能有错别字、缩写、商品名，无法统一统计或对接医保接口。必须引用标准药品库。

• 建独立表 medications，字段含 cn_drug_code（中国药品编码，如 YZ00123456789）、generic_name（通用名）、dosage_form（剂型）
• user_medications 表只存 medication_id 外键，加上 start_date、end_date、frequency（如 "1/day"）、note（患者自述备注）
• 禁止在 user_medications 中存 drug_name VARCHAR(100) —— 这是后期数据清洗灾难的起点

避免过度预设“健康报告”类宽表

有人会想建一张 health_summary 表，字段包括 last_bp_systolic、avg_glucose_7d、step_count_this_month……这类表维护成本极高：每次新增指标就得改表结构，聚合逻辑散落在各处，缓存失效难控制。

更合理做法是：

• 原始数据全存在 health_records 和对应明细表中
• 用视图（VIEW）或应用层定时任务生成聚合结果，存入 health_aggregates 表（按 user_id + date_range + metric_type 主键）
• 前端请求“本周血糖趋势”时，后端查 health_aggregates；若无缓存，则实时聚合 health_records 并回填

真正难的是时间窗口对齐（比如“空腹血糖”需限定在晨起未进食前2小时内）和异常值剔除逻辑，这些没法靠表结构解决，得在业务代码里明确定义。