最近需要搭建一个随时可以用的CMS系统，但是不想用别人开发的系统，于是自己着手设计了一波文章+评论的数据库。
这篇文章主要列一下文章和图集的概要。
!!!! 所有数据，最好不要设置外键
粗略概要图
然后经过细细揣摩后，对这些概要进行MySQL数据表设计（缓存如何存就不说了，每个业务设计不一样），如图：
数据表概览图
这里只对几张表进行字段阐述，因为其他都可以理解清楚的
分类表
分类表
| 字段 | 类型(长度) | 释义 |
|---|---|---|
| 分类ID | int(11) | 主键，也可以使用随机字符串，随意 |
| 分类名称 | varchar(8) | 分类2-4个汉字 |
| 排序 | int(11) | 用于前端显示排序 |
| 创建时间 | int(11) | 时间戳 |
| 父级分类ID | int(11) | 默认0，关联本表的分类ID，主要做二级分类用 |
| 删除时间 | int(11) | 时间戳，用于数据冗余，以后做分析 |
主体表
文章主体表
| 字段 | 类型(长度) | 释义 |
|---|---|---|
| 文章ID | varchar(50) | 主键，使用随机字符串，目前采用 md5(作者账号+随机数) 生成 |
| 标题 | varchar(100) | 标题简要明了，100都多了 |
| 作者 | varchar(20) | 这里主要存储 用户系统 的账号ID |
| 类型 | tinyint(1) | 文章类型 ，1图集，0普通文章 |
| 封面图类型 | tinyint(1) | 默认0无图，1单图，2三图，3自定义 |
| 定时发布时间 | int(11) | 时间戳，在前端展示的时候，定时发布时间应覆盖实际发布时间 |
| 置顶时间 | int(11) | 时间戳，默认最新置顶的在最上面 |
| 通过审核时间 | int(11) | 时间戳，通过审核后更新该字段并异步添加一条审核记录到审核表 |
| 上架时间 | int(11) | 时间戳，用户可自行上下架，上架需审核，下架后重新上架也需要审核。 |
| 发布时间 | int(11) | 时间戳，用户真实发布时间 |
| 删除时间 | int(11) | 时间戳，用于数据冗余，以后做分析 |
分类主体关系表
分类主体关系表
| 字段 | 类型(长度) | 释义 |
|---|---|---|
| 分类ID | varchar(50) | 分类表中的分类ID |
| 文章ID | varchar(50) | 文章表中的文章ID |
| 创建时间 | int(11) | 时间戳 |
| 更新时间 | int(11) | 时间戳，这个字段至关重要，当文章有置顶和定时发布的时候，这个字段应该与文章中的置顶或定时时间同步，方能保证根据分类获取列表时候，可以减小时间排序的误差 |
| 是否生效 | tinyint(1) | 可选1和0，主要用于文章下架后或待审核前，文章不应该出现在分类下；以此字段来过滤分类下的文章ID |
| 删除时间 | int(11) | 时间戳，用于数据冗余，以后做分析 |
这些表设计来的作用是什么呢，我觉得还是举例几个说明比较好（复杂数据都是做过缓存的）：
0.1 获取分类列表(仅限二级)
获取数据时候，进行自关联查询，可以获取到一级和二级的分类列表
获取分类列表
0.2 发布图集
提交数据后，对数据拆分后进行异步存储，分别存储到
文章主体表和图集内容表... ，如果做了缓存，可以先直接存储到缓存，然后异步提交任务，由任务执行者来执行DB操作（没做过线上测试，目前新增数据是采用直接操作DB），可以减少响应时间。
发布图集
0.3 获取图集详情
在查询时候默认查询的是缓存，如果要查询DB，则先查主体表，再查图集内容表
获取图集详情
0.4 删除图集
可以直接仅更改
主体表中文章和分类关系表的删除时间，然后推一个异步任务去更新封面、内容表等其他表，因为只要更新了主体表和分类关系表，就没有文章入口了，其他的自然也查不出来了，把费时的操作拿给任务去做
目前这个数据表的结构配上缓存，还没发现大问题，希望指教
