学习系统 - 目录结构

  1. 1. 节点 & 记录模型
    1. 1.1. 索引上会被加上学习记录
    2. 1.2. ?理论
  2. 2. Metadata
    1. 2.1. - Content Table
      1. 2.1.0.1. 当然还会有一些扩展字段。
  3. 2.2. - Record Table:
  • 3. 实现:
    1. 3.1. 成绩的计算
    2. 3.2. 规则引擎
    3. 3.3. 其它
      1. 3.3.0.1. 用户订阅后,要在记录表里,帮它充满这个表,还是用户学一个填一个?
  • 4. 性能
  • <- 回到首页

    Index Structure

    用户不会直接触达内容,都是从结构到达。

    节点 & 记录模型

    用户在和节点也会产生记录,这些记录标识用户学过哪些内容,学习成绩如何,等一些基本数据,就像学生做试卷,做题记录会记录在卷子上,但在该章节点上,也会写下用户的成绩等。

    img

    索引上会被加上学习记录

    加上学习记录的形态就像这样。

    img

    ?理论

    关于记录着该 object 上的一些附载信息的位置说法:

    内容的 Paradata/Tag/Comment 应该由谁来记? 是记录在 point 上,还是记录在这个 object 本身上???
    (从沪学来看,是记录在 point 上的。)因为这个内容的评论,不希望出现在另外的一个系统中,虽然我们用了同样的内容。

    或者,两个课程中出现了同样的内容,也不希望共享这些评论的信息。

    • Paradata / Tag / Comment 这些公共的和 object 在该位置的一些内容。
    • Record 这些个人的用户和 object 在该位置的一些记录。(passed, unlocked, completed, score)
    1. 就单将 index 作为目录来看。

      它承载的是一个索引,或者是一个指针,自身不存储任何内容。

    2. 如果将 index 还作为三方服务来看,

    • 这些服务,还需要 paradata / tag / comment 吗
    • 这些服务,还需要用户记录 object 的用户数据吗?

    ???? 这个要找产品讨论一下。

    而且比较麻烦的是,它还有性能原因。

    Metadata

    - Content Table

    name description
    id 节点的 id
    title 节点的标题
    description 节点的介绍
    content_id 对应内容 id
    type 类型 (由业务定的类型,task, group, slide…)
    visable 是否可用
    level 节点的等级
    hobby 这些节点的属性,对性能有很高要求,但确定要用在这里吗?
    creator 节点的创建者
    lang 语言
    当然还会有一些扩展字段。

    像沪学中

    • 在 group 中加入了一个封面图片。
    • 沪学中任务列表里配运营位。

    - Record Table:

    name description
    id 记录 id
    userid 用户 id
    unlocked 是否解锁
    score 分值
    best 最好成绩
    passed 是否通过
    compelted 是否完成

    实现:

    • 所有用户任务(带记录中任务进度)
    • 某个任务的章节 (章节暂无数据)
    • 某个章节的卡片 & 子任务 (子任务带学习记录)
    • 用户学习完,更新节点记录 & 内容记录。
    • 当然还要进行录入。

    成绩的计算

    作为一个学习内容的整体,有一些计算的需求,像进度。整体成绩。也有可能要分级计算,每一层级都有计算进度、完成的需求。(沪学目前没有,但不见得以后没有。)

    这些东西(典型的推拉)

    • 可以一次性读数据,然后算出来
    • 也可以在更新时,一次性算好,写入数据库。

    还有一些内容上可变化的部分,当变化到达时,:

    • 用户:学了一个新内容。
    • 系统:新上线/下线 一个内容
    • 系统:新上线/下线 一组内容

    规则引擎

    任何一种变化,都要由该变化点向上层,一直冒泡通知。然后每一层做自己的事。

    沪学举例:子任务完成,通知 group。group 计算完成,通知 section, section 再通知到 task。

    因为有可能会计算到解锁,完成一个 subtask 解锁下一个,完成一个 group,解锁下一个。等等。

    每一个节点上都会有一个(多个)规则,当有变化时,就从自身向上,通知各自的规则响应接收器(同步)。

    name direction description
    task 收到通知后,处理自身事件。
    - - 规则: 计算该 task 的进度(%),
    section 收到通知后,处理自身事件。完后向上通知。
    - - 规则: 计算该 section 的进度(%),解锁相关 section。
    group 收到通知后,处理自身事件。完后向上通知。
    - - 规则: 计算该 group 的进度(%),解锁相关 group。
    subtask Subtask 更新后,从自身向上发起通知。完成后向上通知。
    - - 自身的规则引擎包括:解锁相关子任务

    其它

    用户订阅后,要在记录表里,帮它充满这个表,还是用户学一个填一个?
    • 像网校,它要给课程设定 level,然后为不同的用户解锁不同的 level。
    • 沪学,主要还是订一个记一个的。

    但这是业务上的事,不影响结构。

    性能

    Cache

    如果这样的话,通过 Cache,可以做一些优化。

    内容是不经常变化的,可以直接给 cache 下来。
    如果直接 cache 发现变化点有点多,可以分多层级来 cache。

    每次读数据,然后算出来。

    实现:

    关于

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    刚 tms 内容,插入到 tms
    - 内容侧加入机制
    slides|exercise|words
    解锁
    lrs
    |root_node_id|node_id|type|passed|score|unlocked
    算课程总成绩:
    root_node_id
    file type => slides|exercise|words
    算一个章节:
    |node_id|type|passed|score|unlocked
    章节id从 redis 向下取这几种类型的 ids:=> slides|exercise|words
    算一个 group:
    |node_id|type|passed|score|unlocked
    group id从 redis 向下取这几种类型的 ids:=> slides|exercise|words
    要求我们,
    1. redis 只存 node和sub_node
    2. 全部都存。浪费内存
    • type
    • template

    使用

    • type 在 input 决定。
    • template 由 view 使用,不关心 type。

    决定

    • type 决定数据结构。
    • template 决定显示样式。

    同样一个 type 可能有多个 template,比如说 H5 / Native。
    会有两种 type 共用一个 template 的情况吗?