个人健康管理系统需分离敏感与非敏感用户信息，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 数据。
用药记录必须关联药品标准编码，不能存药品名称字符串
用户手动输入“阿司匹林肠溶片”可能有错别字、缩写、商品名，无法统一统计或对接医保接口。必须引用标准药品库。
开发语言：java，支持数据库：Mysql 5，系统架构：J2EE，操作系统：linux/Windows1. 引言 32. 系统的结构 32.1 系统概述 33. 功能模块设计说明 43.1 商品管理 43.1.1 添加商品功能模块 53.1.2 商品列表功能模块 83.1.3 商品关联功能模块 93.
- 建独立表
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小时内）和异常值剔除逻辑，这些没法靠表结构解决，得在业务代码里明确定义。
