从零开始建站(二) - 数据库与项目规划
简介:
这节来介绍个人网站项目的数据库字段选择与项目整体的规划,上一节讲了准备工作和环境搭建,就好比建一栋大楼,上节我们把材料买齐了,地基打好了,然后我们这节就是来思考一下我们要怎样利用这些材料,以及要用这些材料怎么建成我们想要的大楼。因为是自己来画前台,写后台,所以建成什么样全是我们说了算,这点还是挺舒服的。
一、模块划分
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 前端设计师,女大神,上面也提到了,里面有很多优秀博客:
4.3 很全的颜色代码表,经常用到,建议保存为书签:
http://tool.oschina.net/commons?type=3 : 开源中国颜色代码表
4.4 艺术签名,我的logo就来自这里:
http://www.yishuzi.com/ : 艺术字
4.5 按钮动画特效(这个网站要*,只能帮你到这了):
http://ianlunn.github.io/Hover/ : hover.css
4.6 页面模块块动画特效:
http://mynameismatthieu.com/WOW/ : wow.js
4.7 图标字体(这个网站又要*,为啥好东西都要*):
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,希望自己慢慢学习,慢慢进步。