学习系统 - 目录结构

  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 的情况吗？