Home Explore Help
Register Sign In
18779989085
/
202226701041
1
0
Fork 0
Files Issues 0 Pull Requests 0 Wiki
Tree: d7efc3458e
Branches Tags
202226701041
/
TFPower-prod
/
schema
/
schema.md

schema.md 8.4 KB
History Raw

一、Schema范式设计

训练计划及任务执行模块

训练计划模块描述

根据用户所需要的健身目标，生成的整个训练计划，训练计划中包含了很多子任务。

任务执行模块描述

记录各类型子任务以及每项任务的执行情况

任务类型

  • 一次性任务
  • 周期性任务（每日、每周、每月）

任务状态

  • 一次性任务，可以在任务数据中直接标注完成
  • 周期性任务，虽然整体有完成状态，但是每次的执行都需要有单独的表来记录。

具体范式设计

1. 表设计

1.1 训练计划表 (TrainingPlan)

1.2 任务表 (Task)

字段 类型 说明
objectId String 唯一标识符
createdAt Date 创建时间
user Pointer 关联用户
goal String 健身目标
content String 训练计划详情
tasks Array> 关联的子任务

1.3 任务执行记录表 (TaskExecution)

字段 类型 说明
objectId String 唯一标识符
createdAt Date 创建时间
plan Pointer 关联训练计划
type String 任务类型（一次性任务/周期性任务）
name String 任务名称
status String 任务状态（未完成/已完成）
count Number 执行次数
duration Number 持续时间
frequency String 周期性任务的频率（每日/每周/每月，可选）

1.4 用户表 (User)

字段 类型 说明
objectId String 唯一标识符
createdAt Date 创建时间
task Pointer 关联任务
execDate Date 执行日期
status String 执行状态（完成/未完成）
字段 类型 说明
objectId String 唯一标识符
createdAt Date 创建时间
username String 用户名
email String 用户邮箱
password String 用户密码

2. PlantUML 类图表示

以下是使用PlantUML表示的类图：

@startuml
class User {
  +objectId: String
  +createdAt: Date
  +username: String
  +email: String
  +password: String
}

class TrainingPlan {
  +objectId: String
  +createdAt: Date
  +goal: String
  +content: String
}

class Task {
  +objectId: String
  +createdAt: Date
  +type: String
  +name: String
  +status: String
  +count: Number
  +duration: Number
  +frequency: String
}

class TaskExecution {
  +objectId: String
  +createdAt: Date
  +execDate: Date
  +status: String
}

User "1" -- "0..*" TrainingPlan : owns
TrainingPlan "1" -- "0..*" Task : contains
Task "1" -- "0..*" TaskExecution : executes
@enduml

##打卡签到模块 ###模块描述 用户表是_User表 用户每日登录后，可以打卡签到，记录用户的签到时间，和日期，且每日只能打卡签到一次。

1. 用户表 (_User)

表名：User

字段：

  • objectId：String (用户唯一标识)
  • username：String (用户名)
  • email：String (用户邮箱)
  • createdAt：Date (创建时间)
  • updatedAt：Date (更新时间)

2. 签到记录表 (SignInRecord)

表名：SignInRecord

字段：

  • objectId：String (签到记录唯一标识)
  • user：Pointer (用户，外键，关联到User表)
  • signInDate：Date (签到日期)
  • createdAt：Date (创建时间)

3. 设计注意事项

  • 在 SignInRecord 表中，user 字段使用 Pointer<User> 来表示与用户表的关联。
  • 每个用户每天只能有一条签到记录，因此在 SignInRecord 表中，user 和 signInDate 的组合应当是唯一的。
  • createdAt 字段用于记录每条记录的创建时间，以便于后续的数据追踪。

PlantUML 类图表示

@startuml
class User {
  +objectId: String
  +username: String
  +email: String
  +createdAt: Date
  +updatedAt: Date
}

class SignInRecord {
  +objectId: String
  +user: Pointer
  +signInDate: Date
  +createdAt: Date
}

User "1" -- "0..*" SignInRecord : has
@enduml

二、业务逻辑描述

训练计划的完整逻辑

计划生成逻辑

用户在APP内，通过文本生成整个训练计划。

数据来源

  • 用户输入：用户的健身需求等。
  • 用户体征：性别、年龄、体重等。

结果存储

  • TrainingPlan
    • 计划目标 goal：计划需求标题。
    • 计划详情 content：完整计划内容。

根据训练计划结果，排期生成任务

数据来源

  • 计划详情 content。

文本生成

[
  {
    "objectId": "task_001",
    "createdAt": "2024-12-01T10:00:00Z",
    "plan": "TrainingPlan_001",
    "type": "一次性任务",
    "name": "30分钟有氧运动",
    "status": "未完成",
    "count": 1,
    "duration": 30,
    "frequency": null
  },
  {
    "objectId": "task_002",
    "createdAt": "2024-12-01T10:00:00Z",
    "plan": "TrainingPlan_001",
    "type": "周期性任务",
    "name": "每周力量训练",
    "status": "已完成",
    "count": 4,
    "duration": 60,
    "frequency": "weekly"
  },
  {
    "objectId": "task_003",
    "createdAt": "2024-12-01T10:00:00Z",
    "plan": "TrainingPlan_001",
    "type": "周期性任务",
    "name": "每日步行1万步",
    "status": "未完成",
    "count": 8,
    "duration": 60,
    "frequency": "daily"
  },
  {
    "objectId": "task_004",
    "createdAt": "2024-12-01T10:00:00Z",
    "plan": "TrainingPlan_001",
    "type": "周期性任务",
    "name": "每月体重测量",
    "status": "已完成",
    "count": 1,
    "duration": 10,
    "frequency": "monthly"
  },
  {
    "objectId": "task_005",
    "createdAt": "2024-12-01T10:00:00Z",
    "plan": "TrainingPlan_001",
    "type": "一次性任务",
    "name": "参加健身课程",
    "status": "未完成",
    "count": 1,
    "duration": 45,
    "frequency": null
  }
]

计划执行的逻辑

用户在 TodoList 页面，加载所有计划和子任务。

  • 用户主动填写执行情况并提交。

数据存储

  • TaskExecution：记录每次用户执行情况提交的数据，并在提交后，根据 Task 中持续时间和次数条件，来判断 Task 本身是否标记完成。

计划的完成和统计分析

  • 连表查询，分析用户计划完成的总体情况和进度。

训练计划业务逻辑图例

提示词：{业务逻辑}，您是一名专业的产品经理，请您将上述逻辑的每个过程，用 PlantUML 的时序图表示出来。

业务逻辑图例

下面是根据您提供的业务逻辑描述所生成的 PlantUML 时序图。这个时序图展示了训练计划的生成、执行和完成统计分析的各个过程：

@startuml
actor User
entity APP
entity TrainingPlan
entity Task
entity TaskExecution

User -> APP: 输入健身需求和体征信息
APP -> TrainingPlan: 生成训练计划
APP -> Task: 根据计划生成任务
User -> APP: 查看任务和子任务
User -> APP: 提交任务执行情况
APP -> TaskExecution: 记录执行情况
APP -> Task: 判断任务是否完成
APP -> User: 展示任务完成情况
@enduml

解释

  1. 训练计划生成逻辑：通过用户输入的健身需求和体征信息，生成训练计划，并存储到 TrainingPlan 表中。
  2. 任务生成：根据训练计划的内容生成相关任务，每个任务存储到 Task 表中，并关联到相应的训练计划。
  3. 任务执行：用户在 TodoList 页面查看任务，并提交执行情况。每次执行情况记录在 TaskExecution 表中。
  4. 任务完成标记：通过任务的持续时间和次数条件，判断任务是否标记为完成。
  5. 计划统计分析：通过连表查询，分析用户任务完成的整体情况和进度。