个人健康管理系统不是电商或社交类系统，数据关系相对简单，但对时间精度、单位一致性、隐私字段保护和历史追溯要求高。直接上“用户-订单-商品”式设计会踩坑。
用户主表必须分离敏感信息
身份证号、手机号、紧急联系人等属于高敏字段，不能和基础资料（如昵称、头像）混在一张
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小时内）和异常值剔除逻辑，这些没法靠表结构解决，得在业务代码里明确定义。
