前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >Echo的数据库表是如何设计的

Echo的数据库表是如何设计的

作者头像
飞天小牛肉
发布2021-03-18 14:34:45
8330
发布2021-03-18 14:34:45
举报
文章被收录于专栏:飞天小牛肉飞天小牛肉

Echo 这个项目数据库设计并不复杂,需要我们手动设计的只有四张表:

  • 帖子表:discuss_post
  • 评论表:comment
  • 用户表:user
  • 私信表:message

用户表

解释一下各个字段的含义:

  • id:用户的唯一标识
  • username:用户名
  • password:存储加盐加密后的密码
  • salt:随机生成的盐,用于密码的加盐加密
  • email:邮箱
  • type:用户类型
    • 0 - 普通用户(用户注册默认是普通用户)
    • 1 - 超级管理员:具有删除帖子、访问数据统计界面的权限
    • 2 - 版主:具有置顶、加精帖子权限
  • status:用户状态
    • 0 - 未激活(默认):用户点击注册后未点击邮箱中的激活链接进行验证,就会处于这个状态。未激活的用户同样无法正常使用某些功能比如发表帖子等
    • 1 - 已激活:用户点击邮箱中的激活链接进行验证成功,就会将状态从未激活改成已激活
  • activation_code:激活码。用户点击注册后,随机生成一串激活码,则在本地环境下:http://localhost:8080/greatecommunity/activation/用户id/激活码 成为该用户的激活链接;在服务器上:http://1.15.127.74/activation/用户id/激活码 成为该用户的激活链接。点击该激活链接则激活用户。激活的逻辑也很简单,就是检查一下这个链接中的用户 id 和激活码是否和数据库中存储的一样。

帖子表

解释一下各个字段的含义:

  • id:帖子的唯一标识
  • user_id:发表该帖子的用户的 id
  • title:帖子标题
  • content:帖子内容
  • type:帖子类型
    • 0 - 普通帖子(默认)
    • 1 - 置顶帖子
  • status:帖子状态
    • 0 - 正常(默认)
    • 1 - 精华:为帖子加精可以使其在热度计算中得到一定的加分
    • 2 - 拉黑:管理员删除帖子后,就将这个帖子的状态设置为拉黑
  • create_time:帖子发表时间
  • comment_count:帖子的评论数量(因为会频繁的显示帖子的信息,比如创建时间、创建人、评论数量、点赞数量等,创建时间和创建人信息这张表中已经有了,所以此处再将评论数量存进来就好。可能会有同学会问啥不把点赞数量也缓存到帖子表中,因为点赞数量是存在 Redis 中的,获取点赞数量咱连数据库都不用进的,还费劲在这存一份干啥)
  • score:热度 / 分数(用于按照热度排行帖子)

评论表

这个表应该是相对来说最复杂的一张了。因为不仅有评论(对帖子的评论),还有对评论的回复,都放在这一张表里面了。

  • id:评论/回复的唯一标识
  • user_id:用户 id(哪个用户发布了这个评论/回复)
  • entity_type:实体类型(表示这条 comment 是针对哪个类型的,如果是针对帖子的,那么这个 comment 就是评论;如果是针对评论的,那么这条 comment 就是回复)
  • entity_id:实体的 id(如果是对帖子的评论,就存储帖子的 id;如果是对评论的回复,就存储评论的 id;还有对回复的回复,存储的仍然是所属评论的 id。也就是说,「某个帖子下的所有评论,它们的 entity_id 都是这个帖子的 id。某条评论下的所有回复,它们的 entity_id 都是这条评论的 id」。)
  • target_id:目标用户 id(表示这条评论/回复是针对哪个用户的。比如用户 admin 发了一个帖子,用户 master 评论了这个帖子,那么这里的 target_id 存储的就是用户 admin 的 id。)
  • content:评论/回复的内容
  • status:评论/回复状态
    • 0 - 正常(默认)
    • 1 - 禁用(暂未使用)
  • create_time:评论/回复发布时间

私信表

这张表不仅存储用户之间的私信,也存储系统通知,不同的是,系统通知的 from_id 特定为 1。用于发送系统通知的角色(用户) SYSTEM 已内置。

下面来看私信表的结构:

  • id:私信/系统通知的唯一标识
  • from_id:私信/系统通知的发送方 id
  • to_id:私信/系统通知的接收方 id
  • conversation_id:标识两个用户之间的对话。比如用户 id 112 给 113 发消息,或者 113 给 112 发消息,这两个会话的 conservation_id 都是 112_113。这样,通过这个字段我们就能查出来 112 和 113 之间的私信往来了。当然,这个字段是冗余的,我们可以通过 from_id 和 to_id 推演出来,但是有了这个字段方便后面的查询等操作
  • content:私信/系统通知的内容
  • status:私信/系统通知的状态
    • 0 - 未读(默认)
    • 1 - 已读
    • 2 - 删除(暂未使用)
  • create_time:私信/系统通知的发送时间
本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2021-02-24,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 飞天小牛肉 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 用户表
  • 帖子表
  • 评论表
  • 私信表
相关产品与服务
对象存储
对象存储(Cloud Object Storage,COS)是由腾讯云推出的无目录层次结构、无数据格式限制,可容纳海量数据且支持 HTTP/HTTPS 协议访问的分布式存储服务。腾讯云 COS 的存储桶空间无容量上限,无需分区管理,适用于 CDN 数据分发、数据万象处理或大数据计算与分析的数据湖等多种场景。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档