Skip to content

Latest commit

 

History

History
115 lines (72 loc) · 4.72 KB

Interface.md

File metadata and controls

115 lines (72 loc) · 4.72 KB

功能

  • 账户系统
    • 数据/功能/后端
      • 用户名和密码
        • 不能重复的用户名
      • 顺序数字ID
      • 手机验证
        • Aliyun
      • 邮箱验证
      • 2FA
      • 绑定Bilibili账号
      • 找回密码功能
      • 账户可以是中之人账户，作品（live2d等）作者用户。
    • 前端
      • 登陆，状态
      • 注册页面
      • 以上功能相关页面
  • 企划
    • 数据/功能/后端
      • 数字ID
      • 立绘/人设：对应作品ID
      • live2d：对应作品ID
      • 3D：对应作品ID
      • 中之人：对应账户ID
      • 评论
    • 前端
      • 显示以上状态
  • 作品：立绘/live2d/3D
    • 数据/功能/后端
      • 数字ID
      • 是个live2d还是个3D什么的
      • 评论
      • 浏览照
    • 前端
      • 显示呗

前后端通信指南——（草稿）目前所涉及到的接口整理（原则：能做多少做多少……你看我这两天一直有在做的www）

请参阅UserParser.js，ProjectParser.js和WorkParser.js

Il Harper想出来（但做不出来）的最优化数据存储方法。f*-up预定。

DB里面存储的基本类

1.作品（Work）=》使用唯一ID标识（三种不同类型的作品可以分别标识，就像avxx，cvxx和auxx一样），且存储在作 品 大 数 据 库（WorkDB）里

包含作者（Author），类型（Type），所属企划（Project?）和一个“申请状态列表”（Array[Request]?）。标题时间简介什么的我就不说了。“评论”在后面的“评论和讨论系统”中会有提到。

2.企划（Project）=》也使用唯一ID标识，且存储在企 划 大 数 据 库（ProjectDB）里

包含3个作者（Author?）（中之人在这里按照作者存储），三个作品（Work）。时间简介什么的依旧不说。“讨论”在后面的“评论和讨论系统”中会有提到。

注意：3个“申请状态列表”分别从三个作品类里面提取。

上面两个DB之所以叫大 数 据 库，是因为他们是要在“主页”和“热门”里面展出的，需要分类汇总的主要数据。而在下面的数据类型，如Request等，并不会摆在主页让外人看。高并发预定。这两项数据既需要各个作者的读取，还要使用各种牛逼的推荐算法进行比对（f*-up）。 下面有数据库内容的专项废话。

3.作者（Author）的个人信息这些我就不多说了

注意：依照Readme里面使普通用户产生“我能不能也参与到这个项目里面来？”的想法从而增加活跃用户量的无厘头说法，所有用户都叫做作者（潜 在 作 者）。www你们看吧www

4.作品类型（Type）是个enum，就那三种。

申请（Request）列表

1.申请（Request）之所以要单独做成系统，是因为该系统是联系作品（Work）和企划（Project）的桥梁。

=》使用唯一ID标识，且存储在申请数据库（RequestsDB）里。某Work和Project要GET里面的数据都必须从该DB拿。申请之所以不附属在ProjectsDB里面是处于减少ProjectsDB负载压力的考虑，因为单独的一个申请根本不足以“立项”。

当然也可以单独把“未立项Req”和“Proj内的Req”分开管理，但那样不是更加复杂了吗？

申请（Request）包含：申请类型（RequestType）（下面有），申请状态

2.申请类型（RequestType）包含From（Type）和To（Type）。

3.申请状态（RequestStatus）也是enum。申请中，成功和失败。

大 数 据 库内容相关

1.立绘数据库

标识使用Work的标识，每个立绘都应提供一个PSD（……嘛没有也行）和一张图片。若未提供图片的话后端麻烦拿PSD生成一个。图片在入库的时候也麻烦后端同时生成一个缩略图一块放进去。

这里有一点需要注意：没有PSD的立绘应该提醒用户，因为没有PSD的立绘是无法制作L2D的。

PSD让用户自行选择“不公开”或者“公开且可供下载”。

2.L2D数据库

放进去就行，生成预览图的缩略图的方法同上。呈现器等我找找轮子。

3.3D模型数据库

原理同上，不过这个要公开吗……

评论和讨论系统

得我觉得废话到这里后面的东西已经快要全部f*-up了，，，

每个作品（Work）或是企划（Project）的详情页中都会有这玩意。

为减少DB压力，评论的Depth做成1和2都行（即有没有楼中楼），附加属性最好还是要上（即按照点赞个数排列楼层）。

人工和AI审核系统

这里就不写了www，我觉得只有前面的系统尽善尽美的情况下才会考虑这里的吧……

这玩意是Client的，而且跟什么高考批卷有点像……这里暂时不涉及。