内容简介：

1）学生注册相关的数据表设计

2）数据库索引（indexing）

今天完成的内容：

1）设计了学生注册相关的数据表。

还没实战经验来做出数据库表格的设计，所以选择多做。设计了这么多表来完成这个业务。我的思考如下。（在图中省略了要求的，创建日期，更新日期field）

1. 所有学生应该都已经是修真的注册用户了，所以都应该有关联的user account。

2. user account尽量简单，只有id name password信息。

3. 和用户相关的信息尽量都放倒user_profile表中，这里面的信息不一定是同时搜集的。

4. 一个用户很可能有不止一所学校，假设一个人是北大的本科，清华研究生，复旦的博士，他可能不想全写出来，这是他的选择，可网站应该能实现一个用户有多所学校的功能。所以创建了一个school table 存学校信息，一个user-school table存school和user的多对多关系。

5. 把学生间的师兄弟，辅导员关系用mentorship表存储，以实现师兄弟之间的多多关系。

6. 从哪里认识的修真院，应该是多选的check box所以也建立的多多关系。

7. 一个职业规划(career)下面可以（可能）有多个课程(class)，一个课程可能涉及多个职业，假设将来有一个capstone的大项目课程，涉及到不同职业路线上的师兄弟一起合作。所以用多多(career-class)似乎比较保险 （虽然目前看来职业和课程是1对多关系）

8. 一个课程可以有很多学生，一个学生也可能上完java学android，也可能同时学java和ios，所以学生和课程是多多关系，使用了class_student表

9. 在class_student表中，添加了些field存放和学生报名有关的信息，比如说计划开始日期，学习宣言。这样不同课程有不同计划开始日期，以及宣言。另外，如果报名做出注册网页的话，就应该不需要学员手动填写日报连接了，因为系统自己就可以根据user id 找到用户所有的日报。我能想到日报连接field存在的的理由是让用户自己选一个自己认为写的最好的日报，发上来作为入学写作考核一样的存在。

一些疑惑：

1.这样设计表是不是有点大费周章？其实业务无非是要报名，是不是真的需要这么多表？这种设计做网站，一定是表一堆堆，会不会是网站性能杀手？不知道实际工作中table是如何设计的。

2. 如果另外再没个表里再添加一个deleted 列 int（boolean），这样如果要删除的时候，只是把deleted编程1 （true），而不会真正删除数据，只是改变deleted field，这种设计是否有用？

2）数据库索引是什么（indexing）

在知乎搜索到这篇对索引的解释对indexing有了点认识，由google了些不同的网站上的解释，基本一致。https://zhuanlan.zhihu.com/p/23624390 

现在我理解的indexing就是把一行行的数据以index的那一列为key，变成一个（平衡）树状结构（多为B－tree）

主键（primary key）也是一种索引（indexing），所以如果一个表没有主键，那么这张表中的数据就好似一个无序排列的linkedlist，比如［C,D,E,A,B],如果你要找到E这条数据，则要对这个linkedlist做一个遍历，每条数据都要读一下。

有了索引（比如说主键），这个linkedlist就变成了一个树状结构(如图）。

如果我们想找到B,只需要从M开始，找到EH这里，再找到BD这里，需要做的查询远远小于遍历每条记录。如果再加上数据库是持久层，数据都写在硬盘上，读取数据时io读硬盘的开销，使用index可以大大的降低读取速度。

如果对一个表，在主键以外再添加一个索引，也就是有了另外一个树状的（索引）表存在数据库里面。用user这个table为例，主键id是一个索引，给用户名再加一个索引，既可以使用主键快速找到一个用户，有可以使用用户名快速找到一个用户（比如验证登录的时候，不可能有主键信息，只能通过用户名来找记录。）这样，数据库里其实存了两个树状结构，一个是主键id的树状结构，一个是username的树状结构。

索引虽好，却不是没有缺点。如果使用linkedlist，我们添加一条数据的时候只需要往队列后面加进去就好了，非常快。可如果使用了树状结构，当你要加入一条新数据的时候，要维持队列的树状结构需要额外的时间开销。这样就造成了使用index会导致增删改速度降低。

如果一个用户表（有三个field ， id，username，password）首先id常规来说是主键，那么我们要是再给username加一个索引，那我们就有了两个树状结构的表，一个是id，一个是username。如果我们要添加一个新的用户，数据库要对这两个表进行操作，花费的时间一定是多余只有一个index。加入一张表有10几20个index，那增删改花费时间会变得20倍的多。。。所以index是好钢。。只能用在刀刃上，不应该乱用。

疑惑：感觉user这个table用的最多的是根据用户名的查询，大多数网站，用户名是不能重复的。那么，是不是可以取消id这个field，用username做unique，primary key呢？

明天计划：

计划来实际使用mysql验证下有无index下的增删改查性能区别。