截至今日，已经将没有鉴权、登录等功能的后端实现完成。实际上在9月13日，我就已经配置完成本地的Mysql（偷懒用Navicat），所以今天先记录下数据库的设计过程，后端开发让我头大，后续补上。

　　之前了解过大概的数据库设计流程，但是实操的时候还是凭借着记忆进行了，有不可理的地方，或是名词使用不专业的地方，欢迎指出。

 

　　整个数据库的配置过程如下：

一、草拟前端页面，根据页面的需求确定哪些数据是需要存储的。（设计字段）

　　在我设计的前端界面中，评论的展示采用的是楼中楼的形式，也就是针对博客的评论为一层楼，其余发生在这个评论下的回复均为同级。这样形式的评论显然整齐，但评论数量一多，很容易找不到某一个回复是针对哪一条父评论的（显然现在根本不会面对这样的问题，所以我大胆选用了这种形式）。由于前端的样式还没有开发出来，所以这里放不了展示，用别人的图片又有侵权的麻烦，待日后我回来补充吧。

　　回过头来，一条完整的评论不外乎包括了三个对象的信息：被评论的博客，评论的用户，评论本身。“博客”Blog展示“标题”title，“用户”User展示“昵称”name与“头像”iamge，“评论”Comment展示“时间”time与“内容”content；但这只是前端所展示的，并非数据库所存储的全部内容，这三个对象之间还需要一些其它的“信息”进行联系。　　

 

二、考虑字段间的对应关系，补充字段，设计出多个“对象”，以及对象拥有的主键与外键。不知道用对象来形容是否准确，个人认为便于设计表单。（设计对象，确定主键与外键，主键用 "id" 或 "对象名_id"）

　　User与Blog是完全独立的，而Comment需要将二者联系起来，这就需要对字段进行补充，最基本的，对各个对象都添加 id 作为主键，这样，Comment就可以通过blog_id访问Blog进行定位，通过user_id展示User信息，那么id既是表单的主键，也是表单的外键。

　　但是，Comment与Comment之间还需要一个字段进行联系，就是father_id。设置父评论的father_id为0，将父评论的id作为子评论的father_id，这样后端就可以很轻松地提取分组的Comment。

 

三、将字段按照对象进行分类，对象只拥有属于自己的信息，不拥有对象。一个表单对应一类对象。（将字段划分为多个表单）

　　按照前面步骤的划分，所有的字段共可以分为Blog、User、Comment三个对象。

　　Blog拥有：id，title

　　User拥有：id，name，image

　　Comment拥有：id，blog_id，father_id，user_id，time，content

 

四、到此为止，最基本的设置都完成了。Mysql中还可以对字段、表单进行属性的设置，比如字段的备注、表单主键的自动递增，这些按需设置。虽然是第一次做数据库设计，但是也不是不规范的无头苍蝇。现在在各大网站平台的评论系统都是被开发透透的了，我不会从头设计（因为我既不是蠢蛋，也看不出他们的系统有什么不合理。因此，在设计过程中参考了一些数据库设计的方案，最终形成了这样的数据库。

个人认为，第一次做一件事，可以做出垃圾，但是如果知道是垃圾，却不丢掉或者改正...那是十分不可取的。

————————————————————————————————————————————————————————————————————————————————————————————

 

不敢把话说绝了，我怕我自己也是这样的人。