今日想法：

确定好思路，然后去修改。

今日作为：

之前想到的方案还有已经是半成品的项目。

重新梳理一下，我之前的思路都是很有问题的，过于死板的去向用户的各类操作。

没有考虑到实际开发的接口，其实功能都还是同属于“增删改查”的其中之一。

首先我第一件事就错了，用了多张表来做项目，明明很多东西是可以合成一张表的。

这导致我在后续的开发中要用到连表+父子查询，拼SQL语句又长又难，复杂繁琐。

其次在这个的基础上，我开发接口的思想是以“用户的各类操作”为主，导致开发的接口很多。

两者加在一起，无疑是雪上加霜，超级精品任务三。

详细情况：

我在开发接口的时候是以“用户的各类操作为主”，其结果导致了我要开发很多接口。

返回集合和单例的接口：

从一级查询二级

从一级查询三级

从一级查询二级和三级

从二级查询一级

从二级查询三级

从二级查询一级和三级

从三级查询一级

从三级查询二级

从三级查询一级和三级

这反反复复其实都是查询，算上返回集合和单例，那么就要写十八个接口。

并且附加连表+父子，情况只会越来越复杂困难，一直把自己往死里卡。

后来在各个师兄的引导下，我重新思考了一下。

如果我一开始就用一张表解决所有的数据，并且开发思路以查询为主。

那么我只需要写两个接口就可以了，一个查询父类ID，一个查询子类ID，好好利用PID标签。

剩下的逻辑直接在方法层实现，可以极大的简化SQL语句，并且整体上降低数据库负担和提升性能。

这是先前的多张表，导致要连表+父子查询。

这是后来整合为一张表。

如此一来，我接下来把这个项目好好修改一下，就可以了。

详细流程：

假设前端传入查询某父类的子集。

接收到前端传来的某父类的ID后。

先传入查询父类ID的接口，查到该父类。

在将该父类的信息传入查询子类的接口。

子类接口的逻辑是将收到的ID去查询type父子标签的ID。

这样就能收到该父类的所有子集，并且是任何父类ID都可以操作。

只要和前端约定好，那么你查什么就传什么的父类ID就好。

一个接口解决所有问题。

并且合成一张表后，在配合条件查询，就可以查询整个数据库了。

今日问题：

开发的思想思路很有问题，过于死板，不够灵活。

寻找问题和项目大改让我浪费了大量的时间。

意识到了前期表设计的重要性。

今日学习：

连表查询

父子查询

开发思路？

明日想法：

重新设计表和修改表。

将现有的项目进行大量改进。