计时系统开发前置说明

1. 核心数据关系 (Players & Signups)

players 表与 signups 表为 多对一 关系。即一个报名记录 (signup) 可以对应多个参赛选手记录 (player)，这通常用于处理选手报名一个主组别，但实际参与多个子组别或阶段的比赛。

1.1 业务场景示例

示例 A：多日赛

选手在报名系统中报名了 A 组别
该选手实际需要参加 B、C、D 三个不同的比赛组别。

**数据存储：**
    - signups 表：生成 **1 条** 记录，代表这次报名。
    - players 表：生成 **4 条** 记录，分别对应 A、B、C、D 四个组别。
        - 其中，package_id = A 的记录是 主记录，其 is_main 字段设为 1。
        - 其余 package_id = B、C、D 的记录为 子记录，其 is_main 字段设为 0。

示例 B：赛中赛

选手在报名系统中报名了 A 组别。
该选手同时获得了参加 B 组别（赛中赛）的资格。

**数据存储：**
    - signups 表：生成 **1 条** 记录，代表这次报名。
    - players 表：生成 **2 条** 记录，分别对应 A 和 B 两个组别。
        - 其中 package_id = A 的记录是 主记录，其 is_main 字段设为 1。
        - 对应 package_id = B 的记录为 子记录，其 is_main 字段设为 0。

1.2 关键数据处理规则

• 领物数据：以 signups 表为依据。一个报名记录 (signup) 只对应 一份领物条 和 一次免责声明签署。即使选手参加多个组别，也只需领取一次物资。

• 计时数据：以 players 表为依据进行统计。

  • 人次统计：每个 player 记录代表一个参赛人次。例如，上述示例 A 中，B、C、D 组别的完赛人次会分别累加。
  • 人数统计：需通过 player.sign_id 关联到 signup 表进行去重。例如，上述示例 A 中，虽然有 3 个完赛人次，但只代表 1 个完赛人数。

2.名单编辑与系统交互

报名系统与计时系统是 两个独立的系统，但它们共享基础的比赛和组别定义数据。

2.1 系统职责划分

• 报名系统：负责存储选手的 完整报名信息，包括姓名、手机号、证件号、血型、报名组别等。
• 计时系统：主要关注 计时相关数据，如芯片号、成绩、排名、证书生成等。

2.2 组别映射逻辑

报名系统中的选手组别与计时系统中的选手组别 并非直接一对一映射。在计时系统中进行名单编辑时，支持灵活的映射规则：

• 操作方式：在计时系统的某个目标组别（如 计时A组）下编辑名单时，可以选择关联报名系统中的一个或多个组别（如 报名A组 和 报名B组）。
• 结果：报名系统中属于 报名A组 或 报名B组 的所有选手，在计时系统中都会被统一归入 计时A组 进行管理和计时。