健身App数据模型选型：独立Set ID vs 复合键（Exercise ID+Set Number）

方案1：独立唯一ID #

优势 #

• 动态操作适配性强：不管是修改单个Set的参数（如Reps）、调整Set的顺序，还是删除中间某个Set，都不需要修改主键。所有数据操作直接通过唯一ID定位，逻辑简单高效，完全适配你提到的动态修改场景。
• 数据追踪可靠：唯一ID全程不变，后续做修改日志、历史记录追踪时，不会因为编号变动导致关联混乱，能精准定位每一次对该Set的操作。
• 扩展性好：后续如果需要给Set增加跨Exercise的关联逻辑（比如复制某个Set到其他Exercise），独立ID的结构不需要做任何调整，直接复用即可。

劣势 #

• 多维护一个ID字段，但现在数据库主键的生成（如自增、UUID）都是成熟方案，额外成本可以忽略。
• 从标识上无法直接看出所属Exercise，但通过exercise_id外键关联完全可以解决这个问题，不影响数据结构化。

方案2：Exercise ID + Set Number复合键 #

优势 #

• 标识直观，能直接看出Set所属的Exercise和序号，无需额外关联查询即可理解数据归属。
• 不需要额外维护主键字段，节省少量存储（可忽略）。

劣势 #

• 动态场景维护成本极高：如果用户删除某个中间Set（比如Exercise A的第2组），要么保留空缺的序号（用户体验差），要么批量更新后续所有Set的序号（操作繁琐，容易引发数据一致性问题）；调整Set顺序时，同样需要批量修改序号，逻辑复杂。
• 数据追踪易混乱：序号变动后，同一个Set的标识会改变，后续追踪历史操作时，无法通过固定标识关联所有记录。
• 操作不便：单独引用某个Set时需要传递两个字段（Exercise ID+Set Number），比单个ID的接口设计、数据传递都更繁琐。

最优适配方案：方案1 + 辅助顺序字段 #

结合你的核心诉求，推荐在方案1的基础上，给Set表增加一个position（或display_order）字段，用来维护该Set在所属Exercise中的展示顺序。表结构示例：

-- Exercise表
CREATE TABLE exercises (
    id VARCHAR(36) PRIMARY KEY, -- 或自增INT，根据技术栈选择
    name VARCHAR(255) NOT NULL,
    body_part VARCHAR(100), -- 训练部位
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- Set表
CREATE TABLE sets (
    id VARCHAR(36) PRIMARY KEY,
    exercise_id VARCHAR(36) NOT NULL REFERENCES exercises(id),
    position INT NOT NULL, -- 展示给用户的组序号，可动态调整
    reps INT,
    weight DECIMAL(8,2),
    notes TEXT,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

这个方案的核心好处 #

1. 保留方案1的灵活性：用唯一ID做数据操作的主键，修改、删除、追踪都高效可靠。
2. 兼顾用户体验：通过position字段维护组的顺序，用户调整顺序时只需修改该字段，不需要动主键；如果删除某个Set，可选择自动调整后续Set的position（或提供手动重排按钮），保证展示序号连续。
3. 数据结构化清晰：通过exercise_id外键关联Exercise，结合position字段，既能明确数据归属，又能灵活调整展示逻辑。

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