加油！！！

今天完成的事：

我吐了，再写一遍

深度思考：

5.在内存里拼装数据会节省时间吗？如果不能，为什么要选择单表查询，而不是直接拼装成Sql语句。

不能，防止sql注入，单表查询也利于后面数据库的修改

6.为什么一般而言，不允许使用连表查询，不允许使用复杂的Group By等语句，为什么不允许使用存储过程？

单查询可重用性高，相对简单容易理解，而且做分库等改动较小。与联合查询相比较，单查询需要自己用代码去完成联合查询的逻辑，相对繁琐工作量较大，联合查询只要开发人员能够充分理解并且熟练使用，开发效率会提高很多，但是大量的联合查询会让系统进行分库时改动较大。

group by 缺点：

           1、group by 中的，除了算法使用的字段和group by 以外的字段，其它字段的值是随机的，默认获取的是选择查询索引(where或者group by)的第一条符合分组的记录填充的。

            2、当子查询的结果非常大的时候，数据库服务器的临时表空间会用完，因此多余的查询数据会丢失

            3、子查询生成的临时表，没有索引可用，如果临时表数据很大，则主select语句的效率也很低

            4、子查询结果很大的时候，生成临时表的时间也很长

存储过程的缺点大于优点

1、存储过程这种“一次优化，多次使用”的策略节省了每次执行时候编译的时间，但也是该策略导致了一个致命的缺点：可能会使用错误的执行计划。

2、存储过程难以调试，虽然有些DB提供了调试功能，但是一般的账号根本就没有那种权限，更何况线上的数据库不可能会给你调试权限的，再进一步就算能调试效果也比程序的调试效果要差很多。

3、可移植性差，当碰到切换数据种类的时候，存储过程基本就会歇菜。

4、如果业务数据模型有变动，存储过程必须跟着业务代码一起更改，如果是大型项目，这种改动是空前的，是要命的。

7.为什么响应时间一般不允许超过200MS，怎么查看一个请求从发起到结束，耗费在什么地方了？

看小课堂有讲；

通常来说，人的眼睛对200MS以上的延迟是有反应的，所以一般而言，一整个页面都应该在200MS之内完成。

对于复杂的请求,可以稍微慢一点,毕竟大家还能忍受,能忍的程度跟网站的价值成正比。

简单的用户个人信息这种请求，应该在50MS左右，List的数据，差不多在100MS左右。这是比较正常的数据。

8.为什么要自测，仅仅使用Postman来测试足够吗？什么是本地测试，什么是在开发环境测试？在开发过程中，应该每天部署代码到开发环境吗，为什么？

自测可以提前发现自己代码的bug，尽早处理，postman是用来测试接口的，需要其他测试用其他软件，

测试环境：一般是克隆一份生产环境的配置，一个程序在测试环境工作不正常，那么肯定不能把它发布到生产机上。通常指项目测试，修改bug阶段。

开发环境：开发环境是程序猿们专门用于开发的服务器，配置可以比较随意， 为了开发调试方便，一般打开全部错误报告。通俗的讲，项目尚且在编码阶段，我们的代码一般在开发环境中，不会在生产环境中，生产环境组成：操作系统 ，web服务器 ，语言环境。

部署到开发环境可以尽早发现bug尽早调试处理

9.保存图片有几种方式？什么样的情景下应该使用哪一种？

程序处理存放图片的几种方式

1：放在项目本身得文件夹中，直接部署到服务器上

2：存放在磁盘中，然后数据库中存放路径，读取得时候传路径。这个适合小项目

3：将图片转换成二进制文件，但是不建议这样做，因为会给数据库造成压力。

4：存放在云存储器上，也是在数据库上存地址，不过是云地址，使用得时候给前端，然后前端会自动向专门得云服务器上去获取。所有得安全，优化，带宽，缓存命中，都是由云服务器去保证。（比如：七牛云，阿里云）这个适合电商和社区项目

10.为什么要先写单元测试？单元测试应该包括哪些？在正式打包的过程中，什么样的单元测试应该被屏蔽？在Maven里用什么方法可以跳过单元测试，单元测试应该被跳过吗。

单元测试可以让bug发现的时间提前，可以提前处理一些很小的代码错误。

使用maven.test.skip，不但跳过单元测试的运行，也跳过测试代码的编译。

使用 mvn package -DskipTests 跳过单元测试，但是会继续编译；如果没时间修改单元测试的bug，或者单元测试编译错误。使用上面的，不要用这个

11.为什么提供假数据的时候要求，直接Controller接收请求，在JSP中写死数据返回以用做假数据？为什么提供假数据的时候要求数据完整，有分页尽可能给分页，数据尽可能真实？

直接使用Controller接收请求可以还原真实的使用场景，完整的假数据方便给前端提供开发场景，避免后期还需要返工

12.为什么要写假数据，前后端联调的时候，应该什么时候商定接口文档，接口文档应该谁来维护，如果不提供假数据，会发生什么问题？

项目开始，前后端分析需求就要商定接口文档了，接口文档应该由后端编写，一起维护，如果不提供假数据，就没办法进行接口测试了

13.接口应该怎么定义？一个页面应该只对应一个接口吗？还是一个实体对应一个接口，让前端去组装数据？两者的使用场景是什么？

• 易学习：有完善的文档及提供尽可能多的示例和可copy－paste的代码，像其他设计工作一样，你应该应用最小惊讶原则。

最小惊讶原则(Principle of least astonishment)

最小惊讶原则通常是在用户界面方面引用，但同样适用于编写的代码。代码应该尽可能减少让读者惊喜。也就是说，你编写的代码只需按照项目的要求来编写。其他华丽的功能就不必了，以免弄巧成拙。

• 易使用：没有复杂的程序、复杂的细节，易于学习；灵活的API允许按字段排序、可自定义分页、 排序和筛选等。一个完整的API意味着被期望的功能都包含在内。

• 难误用：对详细的错误提示，有些经验的用户可以直接使用API而不需要阅读文档。

而对于开发人员来说，要求又是不一样的：

• 易阅读：代码的编写只需要一次一次，但是当调试或者修改的时候都需要对代码进行阅读。

• 易开发：个最小化的接口是使用尽可能少的类以及尽可能少的类成员。这样使得理解、记忆、调试以及改变API更容易。

简单的页面一个接口还行，但是功能复杂的页面使用一个接口，会造成编写难度加大，逻辑混乱出现bug，一个实体类对应一个接口，前端去组装数据

14.多层分类应该怎么设计表结构，分别有什么问题？像文章分类这种需求，如果分类不确定，级别不确定，有可能动态调整，数据量和访问量又比较大，该怎么去设计？

后台目录列表显示：

   默认显示一级目录列表

   一级目录下可以添加二级子目录，展开可以显示二级子目录列表。

   二级目录下可以添加三级子目录，展开可以显示三级子目录列表。

   往下依次类推实现多级目录显示。

课程选择多级目录显示（使用级联下拉显示）（多级级联实现+jquery控制）

15.什么是实体表，什么是关系表，一对多和多对多应该怎么设计表？ 

实体表就是对应实际的对象的表，而关系表不代表一个对象，而是对象间的关系

一对多两张表，多的表加外键；多对多三张表，关系表两外键

16.什么是外键，用处是什么，为什么不建议使用外键做关联？

外键是相对于主bai键说的，是建立表之间的联系的必须的前提。

性能问题

假设一张表名为user_tb。那么这张表里有两个外键字段，指向两张表。那么，每次往user_tb表里插入数据，就必须往两个外键对应的表里查询是否有对应数据。如果交由程序控制，这种查询过程就可以控制在我们手里，可以省略一些不必要的查询过程。但是如果由数据库控制，则是必须要去这两张表里判断。

并发问题

在使用外键的情况下，每次修改数据都需要去另外一个表检查数据,需要获取额外的锁。若是在高并发大流量事务场景，使用外键更容易造成死锁。

扩展性问题

这里主要是分为两点

做平台迁移方便，比如你从Mysql迁移到Oracle，像触发器、外键这种东西，都可以利用框架本身的特性来实现，而不用依赖于数据库本身的特性，做迁移更加方便。

分库分表方便，在水平拆分和分库的情况下，外键是无法生效的。将数据间关系的维护，放入应用程序中，为将来的分库分表省去很多的麻烦。

技术问题

使用外键，其实将应用程序应该执行的判断逻辑转移到了数据库上。那么这意味着一点，数据库的性能开销变大了，那么这就对DBA的要求就更高了。很多中小型公司由于资金问题，并没有聘用专业的DBA，因此他们会选择不用外键，降低数据库的消耗。

相反的，如果该约束逻辑在应用程序中，发现应用服务器性能不够，可以加机器，做水平扩展。如果是在数据库服务器上，数据库服务器会成为性能瓶颈，做水平扩展比较困难。

17.什么是数据库范式，是否应该严格遵守范式，什么情况下应该不遵守范式？ 

数据库中三bai大范式的定义如下：

1、第一范式：

当关系模式zhiR的所有属性都不dao能在分解为更基本的数据单位时，称R是满足第一范式的，简记为1NF。满足第一范式是关系模式规范化的最低要求，否则，将有很多基本操作在这样的关系模式中实现不了。

2、第二范式：

如果关系模式R满足第一范式，并且R得所有非主属性都完全依赖于R的每一个候选关键属性，称R满足第二范式，简记为2NF。

3、第三范式：

设R是一个满足第一范式条件的关系模式，X是R的任意属性集，如果X非传递依赖于R的任意一个候选关键字，称R满足第三范式，简记为3NF。

范式只是为了可以为你理清数据库的关系的，但是有些情况采用范式的代价要比不采用范式的代价大就可以不适用范式。比如增加了程序逻辑，多联接关系表，不常更新或不更新的基础表信息都可以不必须按照范式的规范来设计。

范式主要为了减少数据库的冗余，但是有时也会为了查询速度来换取数据库冗余

明天计划的事：先停几天任务，复习下框架和注解

遇到的困难：

收获：