前言

这篇文章记录下根据网站功能设计数据库。由于是个人网站随意玩的，所以功能和开发步骤上都是比较随意的。

一般数据库设计都需要经过需求分析、概念结构设计、逻辑结构设计...等阶段。但毕竟个人网站，就没必要这么麻烦了。所以流程可能不是很规范^-^

当然了，会记录大致的设计流程，相信看完小白也能够自己设计数据库了，那么正式开始~

数据库设计

暂时打算设计实现的功能（业务逻辑）如下。

根据上面业务逻辑可以暂时确认的实体有：用户、文章、管理员
而管理员可以理解为管理权限的用户，即管理员可以认为就是用户。那么暂时实体就只有用户、文章，它们应该有以下属性。

然后需要根据业务逻辑确认实体间动作的关联

文章是由用户创建编辑的，文章 --属于--> 用户，用户和文章有 1对多 的属于关系。
用户还可以对文章有这些动作：读、赞、藏、评。用户可以对多篇文章有这些动作，文章也可以被多个用户执行这些动作。此时用户和文章有 多对多 的关系（读、赞、藏、评）。
某些关系在某些时候是可以归纳在一起的：比如读、赞、藏这类都比较类似，如果只是简单记录就可以归纳在一块，只需加个属性（类别）区分。
而某些时候单独记录可能又要好一些：如当有足迹功能时候、或当有收藏集的时候，单独分离出一个关系表也许要方便点。
至于具体如何设计这些关系，可根据具体需求情况而定。根据数据库设计范式，也为了方便后面扩展，个人建议将关系表尽量分离。

根据实体关系大致绘制的E-R图如上，绘制不是很详细，可以后面设计表时再进行优化。比如划分出文章类型、划分三方登录、用户和文章的读、赞、藏关系表分离。

将E-R图转换成关系模型就是将E-R图的实体、属性、关联转化成关系模式，可以简单理解为就是将E-R图转成关系型数据库中表结构。一般二元联系有这些转换规则。

实体转化：实体转化为关系模式，实体属性就是关系属性，实体主键就是关系的码（主键）.
实体关联的转化：
- 1:1 任选一个实体的关系模式上添加另一实体的主键
- 1:n 在n端实体的关系模式上添加另一实体的主键
- m:n 需将关系转化成实体，关系的属性作为关系模式的属性，并添加m、n两端的实体主键

一般地，将参与联系的实体的数量称为联系的度。两个实体之间的联系度为2，称为二元联系；三个实体之间的联系度为3，称为三元联系

当前想实现的功能没有涉及三元联系的实体，此篇暂时就不具体介绍三元联系的转化了。

根据上面的E-R图可转化下面这些关系模式

根据数据库设计范式优化当前关系模式。

三方登录信息记录在用户表上，每增加一个三方登录都需要在用户表开辟新的属性，应拆分出一个三方登录表。
用户的常规信息、账号信息可再拆分一张表，一张存用户登录、密码等信息，另一张存用户头像、年龄等信息。
用户权限（是否管理员）可再拆分，通过角色来控制权限，不同角色有不同的权限。添加角色表和权限表，另外角色和权限是多对多关系（一个角色可以有多个权限、多个角色可以有同一个权限）；角色和用户又是多不多关系（一个用户可以有多个角色、多个用户可以有同一个角色）。即还需要角色权限关联表和用户角色关联表
收藏表应拆分出一张收藏分类表。

最终有以下关系表