如何设计可存储Profile各字段下四方向取值的适配数据模型

方案1：固定宽表结构化存储 #

适用场景：业务字段数量长期固定、查询逻辑简单，仅需高频拉取单分区取值
实现方式：将每个业务字段对应的4个方位值直接拆为独立字段挂载在Profile主表下，比如passing_right、passing_left等字段直接建库列存储。

• 优势：单值查询无需额外关联或解析，数据库层可直接对每个分区值建索引、做范围筛选，原生支持严格的数据类型校验
• 劣势：新增业务字段需要持续做表结构变更，字段量较多时容易触发数据库单表列数上限；后续若要为单个分区值补充附加属性（如取值置信度、数据来源），扩展成本极高

-- 示例建表结构
CREATE TABLE user_profile (
  id BIGINT PRIMARY KEY,
  user_id BIGINT UNIQUE,
  passing_right INT,
  passing_left INT,
  passing_top INT,
  passing_bottom INT,
  receiving_right INT,
  receiving_left INT,
  receiving_top INT,
  receiving_bottom INT,
  shooting_right INT,
  shooting_left INT,
  shooting_top INT,
  shooting_bottom INT
);

方案2：嵌套JSON结构化存储 #

适用场景：业务字段会动态调整、无复杂跨分区聚合查询需求
实现方式：在Profile主表中单独设置JSON类型字段，按照固定结构存储所有业务字段的分区值，无需拆分多列。

• 优势：新增业务字段无需修改表结构，存储紧凑，单次查询即可拿到单个Profile的全部分区值
• 劣势：JSON内部值的索引、筛选维护成本较高，数据类型校验需要业务层兜底

// 示例JSON存储结构
{
  "passing": {"Right": 82, "Left": 76, "Top": 85, "Bottom": 71},
  "receiving": {"Right": 78, "Left": 81, "Top": 73, "Bottom": 79},
  "shooting": {"Right": 90, "Left": 68, "Top": 87, "Bottom": 83}
}

方案3：关系范式拆分存储 #

适用场景：业务需要长期迭代扩展、需要对分区值做跨Profile的统计分析
实现方式：拆分为主表+明细表的二元结构，主表存储Profile基础信息，明细表按「ProfileID + 业务字段名 + 方位标签 + 取值」的三元组结构逐行存储每个分区的值，提前通过联合唯一键避免重复写入。

• 优势：业务字段、方位分区可无限制扩展，后续新增指标、新增分区都不需要修改表结构；支持灵活的跨维度聚合分析；可为每个分区值独立挂载附加属性
• 劣势：拉取单个Profile的全量数据需要关联明细表，数据量大时可通过预聚合缓存降低查询开销

-- Profile主表
CREATE TABLE profile_main (
  id BIGINT PRIMARY KEY,
  user_id BIGINT UNIQUE,
  created_at TIMESTAMP
);
-- 分区取值明细表
CREATE TABLE profile_zone_metric (
  id BIGINT PRIMARY KEY,
  profile_id BIGINT REFERENCES profile_main(id),
  metric_name VARCHAR(32),
  zone_tag VARCHAR(16),
  metric_value NUMERIC,
  updated_at TIMESTAMP,
  UNIQUE KEY uk_profile_metric_zone (profile_id, metric_name, zone_tag)
);

选型决策参考 #

• 业务字段固定在20个以内、以单值查询为主，优先选宽表方案，开发成本最低
• 业务字段会持续新增、无高频跨值分析需求，优先选嵌套JSON方案，存储和查询的平衡度最优
• 长期需要迭代功能、要对分区值做业务统计，直接上关系拆分方案，长期维护成本最低

内容的提问来源于stack exchange，提问作者Vijay L