简介：
这节来介绍个人网站项目的数据库字段选择与项目整体的规划，上一节讲了准备工作和环境搭建，就好比建一栋大楼，上节我们把材料买齐了，地基打好了，然后我们这节就是来思考一下我们要怎样利用这些材料，以及要用这些材料怎么建成我们想要的大楼。因为是自己来画前台，写后台，所以建成什么样全是我们说了算，这点还是挺舒服的。
一、模块划分
1.多浏览
开始我也不知道自己网站要建成什么样子，然后去百度搜索了一下优秀的个人博客网站，找到一个女才子杨青的个人博客，而且她的网站里面还有一个优秀的个人博客链接，里面的很多博客给了我很大的启发。不多说，上图：
2.总结归纳
当你看过很多博客后，我们就可以归纳一下。如果你是想写点东西展示出来的话，个人博客大致就可以包含以下几个模块：文章、日志、随笔、实时新闻、生活、歌曲讨论、电影交流、游记、文章归档（也可以叫时光轴）、关于我、留言簿等等。你可以选取自己需要用到的。像我这的网站文章区就选取了两个，一个写一些技术方面的东西，另一个发表一下自己的心情、琐事、讨论一些有趣的话题等。其他的模块基本就无关紧要，点缀一下而已。
3.简单介绍一下我的网站的文章区的构造及功能：
3.1 文章列表：显示文章的粗略信息
3.2时间（或日期）：提醒我时间的宝贵
3.3公告板：展示一些鸡汤文，提醒自己努力奋斗
3.4 链接：把自己的几个常用网站互相关联，打造自己的标签
3.5 文章分类：快速定位自己想要寻找的文章
3.6 阅读排行：显示出网友所关心的文章，这样分析下来，其实每一个模块都是有用的，不是放在那里单纯摆设的，所以我要先想好自己需要什么，再去想怎么构造好它。（小提示，开始我也是缘于兴奋，把网站页面弄的花里胡哨的，后来网站建好后，慢慢以读者的角度去看待，发现真的很扎眼睛，然后我就化繁为简，只留了几个小幅度的动画效果和淡雅的颜色，还去掉了非主流的动态背景图，而且还能提高网站的加载速度）
4.页面润色
既然说到界面的审美和优化，我就推荐几个我在建站中遇到的几个十分有帮助的网站，供大家参考：
4.1前端大神，各种前端素材，前端教程，动画，小技巧，反正牛逼就是了：https://www.cnblogs.com/lhb25/ ： 梦想天空
4.2 前端设计师，女大神，上面也提到了，里面有很多优秀博客：http://www.yangqq.com/ ： 杨青
4.3 很全的颜色代码表，经常用到，建议保存为书签：http://tool.oschina.net/commons?type=3 ： 开源中国颜色代码表
4.4 艺术签名，我的logo就来自这里：http://www.yishuzi.com/ ： 艺术字
4.5 按钮动画特效（这个网站要FQ，只能帮你到这了）：http://ianlunn.github.io/Hover/ ： hover.css
4.6 页面模块块动画特效：http://mynameismatthieu.com/WOW/ ： wow.js
4.7 图标字体（这个网站又要FQ，为啥好东西都要FQ）：http://fontawesome.dashgame.com/ ：fontawesome.css
还有一些我这里就不一一介绍了，有心的可以自己找。
二、数据库
1.数据库建表规则：
三大范式：
＞一张表中的每一个属性都不能再分，确保每一列的原子性（举个栗子：文章表中包含有用户名这个字段，用户不但有用户名，还有其它地址和电话信息，这个时候就要把用户拆出来新建一个用户表，用userId来关联）
＞首先满足第二范式，然后要求表中的所有列，都必须依赖于主键，而不能有任何一列与主键没有关系，也就是说一个表只做一件事情（举个栗子：订单表中存在产品名称和产品折扣字段，那么这个产品折扣与订单主键订单号没有半毛钱关系，他与产品主键有关系，应该放在产品表中）
＞首先满足前两个范式，然后数据不能存在传递关系，即没个属性都跟主键有直接关系而不是间接关系（再举个栗子：还是订单表中存在订单ID、顾客ID、顾客姓名、顾客地址，虽然顾客姓名和地址跟主键订单ID，有关联，但是他不是直接关联，而是通过顾客ID传递关联，所以订单表应该只存在顾客ID就够了）
三大军刀：
忘了以前从哪里听来的这个词，大概意思是这几个字段雷打不动
＞id
＞create_time
＞modified_time
＞is_delete(这个可加可不加，用于逻辑删除时需要加)
2.建表：
文章表article：我把文章和话题共用一张表（评论数可以通过连评论表查询，但是我这里增加了一个评论数的字段，为了提高查询速度，不推荐这样做）
|
字段 |
长度 |
非空 |
备注 |
|
id |
VARCHAR(36) |
NOT NULL |
主键ID |
|
title |
VARCHAR(100) |
NOT NULL |
文章标题 |
|
image |
VARCHAR(200) |
NOT NULL |
文章配图 |
|
summary |
VARCHAR(300) |
NOT NULL |
文章简介 |
|
type |
TINYINT(1) |
NOT NULL |
文章类型：0-博客 1-话题 |
|
read_number |
INT(10) |
NOT NULL |
文章阅读量 |
|
comment_number |
INT(10) |
NOT NULL |
文章评论数 |
|
thumb_up_number |
INT(10) |
NOT NULL |
文章点赞数 |
|
create_time |
DATETIME |
NOT NULL |
创建时间 |
|
modified_time |
DATETIME |
NOT NULL |
修改时间 |
文章内容表article_content：因为文章内容数据量很大，所以文章内容单独用一张表，这样单纯查询文章列表的时候，效率会高一些：
|
字段 |
长度 |
非空 |
备注 |
|
id |
VARCHAR(36) |
NOT NULL |
主键ID |
|
content |
MEDIUMTEXT |
NOT NULL |
文章内容 |
|
article_id |
VARCHAR(36) |
NOT NULL |
文章信息ID |
|
create_time |
DATETIME |
NOT NULL |
创建时间 |
|
modified_time |
DATETIME |
NOT NULL |
修改时间 |
文章与分类关联表article_category：因为文章表与分类表是多对多的关系，所以我们用一个中间表来关联他们（这个articleId其实应该叫accessId更好因为它也可能是放的图片ID，跟图片表关联，我懒得改字段了，将就着用啦）：
|
字段 |
长度 |
非空 |
备注 |
|
id |
VARCHAR(36) |
NOT NULL |
主键ID |
|
article_id |
VARCHAR(36) |
NOT NULL |
分类ID |
|
category_id |
VARCHAR(36) |
NOT NULL |
文章ID |
|
create_time |
DATETIME |
NOT NULL |
创建时间 |
|
modified_time |
DATETIME |
NOT NULL |
修改时间 |
分类表category：我们考虑到图片和后期扩展别的模块也要有分类，所以我们用一个type字段来区分：
|
字段 |
长度 |
非空 |
备注 |
|
id |
VARCHAR(36) |
NOT NULL |
主键ID |
|
name |
VARCHAR(50) |
NOT NULL |
分类名称 |
|
type |
VARCHAR(3000) |
NOT NULL |
类型：0-文章 1-话题 2-图片 |
|
create_time |
DATETIME |
NOT NULL |
创建时间 |
|
modified_time |
DATETIME |
NOT NULL |
修改时间 |
文章评论表comment：最开始我也设计了用户表，如果设计用户表就要考虑注册的问题，但是想了想我的网站也没什么人看，没人会注册，所以就又去掉了。然后评论就改成了随意填用户名的方式，所以这里也就成了用户名和头像地址都在评论表中。（如果有用户表，应该拆出一个单独的用户表）
|
字段 |
长度 |
非空 |
备注 |
|
id |
VARCHAR(36) |
NOT NULL |
主键ID |
|
article_id |
VARCHAR(36) |
NOT NULL |
文章信息ID |
|
content |
VARCHAR(3000) |
NOT NULL |
评论内容 |
|
user_name |
VARCHAR(60) |
NOT NULL |
评论者昵称 |
|
image |
VARCHAR(100) |
NOT NULL |
评论者头像图片路径 |
|
create_time |
DATETIME |
NOT NULL |
创建时间 |
|
modified_time |
DATETIME |
NOT NULL |
修改时间 |
留言表message：这个就不多介绍了，就是比评论表少一个article_id字段
|
字段 |
长度 |
非空 |
备注 |
|
id |
VARCHAR(36) |
NOT NULL |
主键ID |
|
content |
VARCHAR(3000) |
NOT NULL |
留言内容 |
|
user_name |
VARCHAR(60) |
NOT NULL |
留言者昵称 |
|
image |
VARCHAR(100) |
NOT NULL |
留言者头像图片路径 |
|
create_time |
DATETIME |
NOT NULL |
创建时间 |
|
modified_time |
DATETIME |
NOT NULL |
修改时间 |
回复表reply：这个回复表与两张表有关联（评论表和留言表），comment_id可能存放评论表的ID，也可能是留言表的ID：
|
字段 |
长度 |
非空 |
备注 |
|
id |
VARCHAR(36) |
NOT NULL |
主键ID |
|
comment_id |
VARCHAR(36) |
NOT NULL |
评论ID |
|
content |
VARCHAR(3000) |
NOT NULL |
回复内容 |
|
user_name |
VARCHAR(60) |
NOT NULL |
回复者昵称 |
|
image |
VARCHAR(100) |
NOT NULL |
回复者头像图片路径 |
|
create_time |
DATETIME |
NOT NULL |
创建时间 |
|
modified_time |
DATETIME |
NOT NULL |
修改时间 |
每日一语表everyday_talk：这个表的ID我是按1开始自增的，在后台启用了一个定时任务，在每天的凌晨把保存的静态变量ID自增1，然后查询出内容保存另一个静态变量供前台调用。
|
字段 |
长度 |
非空 |
备注 |
|
id |
VARCHAR(36) |
NOT NULL |
主键ID |
|
content |
VARCHAR(3000) |
NOT NULL |
每日一语内容 |
|
create_time |
DATETIME |
NOT NULL |
创建时间 |
|
modified_time |
DATETIME |
NOT NULL |
修改时间 |
因为第一次设计，所以我并不是先设计表再设计前后台的，因为我也不知道要用哪些字段，所以我先画的页面，作为一个后端开发，画一个前端页面的确是难，我一边学着vue框架，一边画着页面，然后就耗了太多时间，搞的自己都有点疲了，后来搞后端就一切从简了，数据库表也尽量简单来了。
三、需求分析图
1.前台：
2.后台：
这节就写到这吧，其实我感觉这节没什么写的必要。不过激动人心的时刻就要来了，下节我们就要开始搭前端项目，写前端代码了，因为我也不懂前端，所以前端代码写的很low，希望自己慢慢学习，慢慢进步。