EOS 05 - DAPP 的业务逻辑和数据表设计

pendingauth · 2019年06月28日 · 55 次阅读

本文转载自币乎,作者松果,原文链接: https://bihu.com/article/1119873839

DAPP的业务逻辑

微文DAPP是一个类似于微博的内容平台,引入了通证(代币),先做一些比较简单的业务逻辑:

发微文

  • 用户可以发布纯文字或带有附件(链接、IPFS哈希值、图片、视频等)的微文;

评论

  • 可以对微文进行评论;

  • 可以回复他人的评论;

点赞

  • 可以对微文或评论进行点赞;

  • 每个用户每天前10次点赞获得代币奖励;

  • 持仓代币数大于0才能获得点赞收益;

  • 每次点赞,点赞者和作者都将获得相同数量的代币;

  • 点赞获得的代币数量由一个简单算法算出;

  • 具体为每次点赞获得(持仓代币 * 0.00001 * 100~500随机数)的代币;

  • 不能给自己点赞;

关注

  • 可以关注/取关其他用户;

通证

  • 微文DAPP发行内部通证WEI,总量1000亿;

  • 5%即50亿WEI,分配给开发者;

  • 25%即250亿WEI,分配给运营池;

  • 70%即700亿WEI,分配给激励池(点赞挖矿和登录领币);

登录领币

  • 每个用户每天可领一次WEI,越早参与领取越多;

  • 前30天,随机领取10000~50000WEI;

  • 第31-120天,随机领取5000~20000WEI;

  • 第121-360天,随机领取2000~10000WEI;

  • 第360天以后,随机领取1000~5000WEI;

注意

以上业务逻辑主要用于演示DAPP的开发,设计得比较简单,如果是商用DAPP,则需要根据自己的业务场景对逻辑进行优化。

DAPP的数据表设计

微文DAPP的业务逻辑都是写在智能合约中的,数据库设计使用的是multi_index表,根据上面的业务逻辑,需要设计如下几张数据表:

用户表

TABLE usertable {
  name account;                   //EOS账户
  asset balance;                  //代币余额
  uint32_t follow_num;            //关注数
  uint32_t fans_num;              //粉丝数
  uint32_t post_num;              //微文数
  uint32_t like_num;              //获赞数
  time_point_sec last_reward_time;//上次领币时间
  time_point_sec last_like_time;  //上次点赞时间
  uint32_t like_times;            //当天已点赞次数

  uint64_t primary_key() const { return account.value; }
};

微文表

TABLE posttable {
  uint64_t id;              //自增id
  name author;              //作者
  std::string content;      //内容
  uint32_t attachtype;      //附件类型 0=无 1=url 2=ipfs hash 3=file
  std::string attachment;   //附件
  time_point_sec time;      //创建时间
  asset balance;            //获得代币数
  uint32_t like_num;        //获得赞数
  uint32_t comment_num;     //评论数

  uint64_t primary_key() const { return id; }
  uint64_t get_secondary_1() const { return author.value; }
};

评论表

TABLE commenttable {
  uint64_t id;              //自增id
  uint64_t post_id;         //微文id
  name author;              //评论者
  time_point_sec time;      //创建时间
  asset balance;            //获得代币数
  uint32_t like_num;        //获得赞数
  uint64_t pid;             //父级评论id
  name reply_to;            //回复 @账户名:xxx 

  uint64_t primary_key() const { return id; }
  uint64_t get_secondary_1() const { return post_id; }
  uint64_t get_secondary_2() const { return author.value; }
};

点赞表

TABLE liketable {
  uint64_t id;              //自增id
  uint32_t type;            //点赞类型 1=微文点赞 2=评论点赞    
  uint64_t type_id;         //微文或评论的id
  name author;              //点赞者

  uint64_t primary_key() const { return id; }
  uint64_t get_secondary_1() const { return type_id; }
  uint64_t get_secondary_2() const { return author.value; }
};

关注表

TABLE followtable {
  uint64_t id;              //自增id
  name from;                //关注者
  name to;                  //被关注者

  uint64_t primary_key() const { return id; }
  uint64_t get_secondary_1() const { return from.value; }
  uint64_t get_secondary_2() const { return to.value; }    
};

因为multi_index表的定义很长,一般会使用typedef再定义一个别名。

Tips

项目代码在Github同步更新:https://github.com/songguo6/weiwen-dappmulti_index表设计是写到[weiwendappss](https://github.com/songguo6/weiwen-dapp/blob/master/contracts/weiwendappss/weiwendappss.cpp)合约中的,更多细节点击源码查看,下一篇文章编写通证合约。,以上

暂无回复。
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册