仿朋友圈功能 后台关系型数据库设计构想

仿朋友圈功能 后台关系型数据库设计构想

我不知道微信后台咋设计的，纯粹为了解决自己的实际问题想的，做个记录给自己看。

数据存储分为三个部分：

1.       分享记录存储 Share表
2.       分享用户对应权限Share_user_mapping表
3.       评论Share_comment表

表1：

    主键：自生成Share_id

    标签 | 分类 | 点赞/点踩数 | 内容一（文字）| 内容二（图片地址数组或者视频连接）| 创建时间。。。。。

表2：

    主键: 自生成id

    一个userid对应多个ShareId用逗号隔开，按月水平分组，防止单个字段数据过长

    索引  userId,ShareId,年月 组合索引

    id | userId | shareIdList | 创建年月 | 权限类型 |创建时间。。。。。

表3：

   主键：自生成id

   索引  组合索引 UserId_ShareId,  

   id | userId | shareid | createTime | 评论内容 | 回复人 | 点赞还是评论

一、数据插入时

    分享内容时，前段传入，分享相关的主表内容后，还需要传入相关的有可见权限的人或者分组，后台处理后，同时插入表一、表二（表二有则改，无则增），表三在实际操作上或者说逻辑上都是较为独立的。

二、表二特点

    表二采取一对多、水平拆分数据的方式，能极大优化数据量以及按照用户id检索分享id时的查询速度，缺点是按照分享id查询有权限可见用户的ID这一操作几乎不可实现（微信朋友圈亦没有实现）

 

错误的尝试：

 表二：排序之后的用户id各种组合分组控制权限，数据量爆炸，放弃。

 表二：用户id与ShareId一一对应记录，数据量爆炸

 表二：权限控制粗化，在表一做范围权限 记录，表二做一对一辅助记录， 逻辑复杂度提升，不够灵活，影响查询效率。

 表二：不进行年月分组，ShareIdList单个字段数据量Bigtext可以容纳32亿字符，但会极大影响查询效率，在查询分享时通常都是从最近的时间开始查询的，而且这种存储方式不合理，后期不好维护，所以这里按照年月对数据进行分组。

 

MySQL主键Varchar在超过255时会报错好像？？mark一下