2017-07-18&19

目录

• 数据库
• 一些感想
• 一些憧憬

数据库

1. for循环里写操作数据库是大忌！尤其是这种情况：一次查询的结果中有一个记录还要继续展开查询，两次查询的记录均不止一条。就很容易写成for循环里操作数据库了。解决办法就是循环里的每条sql语句结果合并集体查出放到内存中，简而言之就是用空间换时间。（当然不是绝对，这也是空间换时间~
2. distinct关键字要少用，因为内部实现是先对表排序，所以如果不distinct时重复数据较多的话，这种查询就得要想办法加条件使得表变小。
3. 对于非一对多关系的两个表（左、右）外连接的主次表是有讲究的。A左连接B和B左连接A有可能效率不同，因为产生的记录数量不同。（外连接是指定的左表的所有行，而不仅仅是连接列所匹配的行。如果左表的某行在右表中没有匹配行，则在相关联的结果集行中右表的所有选择列表列均为空值。
4. 我们的项目中基本每个实体表都有两个属性IsUse和IsDel，基本上做连接操作时都要加上两个and条件，前者为1后者为0。这样就可能产生一种情况，如果A、B是从属关系，理论上A中的某条记录IsDel是1，那么B对应的属下记录的IsDel也应该是1，但要防止脏数据，所以这时各条IsUse和IsDel条件的位置就很重要了。稳妥的办法是放到where语句中而不是作为连接的条件（on），或者养成从主次表对应从属表，即大表作为主表。
5. 上面那点可能有点拗口，其实就是想说明一个道理：业务虽然不是什么技术性的活儿，但是很讲究逻辑，特别细节。这也许就是bug永远存在的原因之一吧，小小的一个细节看似没关系，但是因为其他原因导致脏数据产生了连锁反应，需要通过更严谨的逻辑去排除这些数据。
6. 让一列数据赋值到另一列上，需要产生一个新表。例如让A的a列等于b列，则要做自身连接，而不能直接的a=b。
7. 以前在书上看到sql语句总用大写其实是有规律的，就是关键字大写，这样是为了方便区分。
8. 写多表连接的sql语句时可以采用分而治之的方法，但是这要求非常熟悉简单的sql书写，并且写之前应该明确已知条件和查询的结果。（套用句式：通过什么去查找什么）

一些感想

1. bug永远都改不完，我想归根到底是一开始规划不可能十全十美，导致后期迭代的时候有些东西就改不了，因为牵一发而动全身，这也正是重构出现的原因吧。
2. 在校学习的内容确实也是工作的内容，所谓工作经验可能更多是对知识运用的习惯（如命名风格，代码风格等），恰恰这一点能看出一个人高下。
3. 开始进入第一个瓶颈期了：可以做简单的任务，但是不愿意学习新的东西了。其实也是自己一直以来的一个缺点，沉不下心去深入了解一个知识，心太杂了，缺点什么呢？
4. 一直说自己细心，当写sql语句时就发现并不是这样的，还经常开小差。
5. 自己还很容易受外界声音干扰，稍微有些声音就不能专心自己的事。

一些憧憬

1. 今天终于看到了所谓的服务器了~应该是Windows server系统。突然想学学什么是把服务放在云上以及怎么做，或者说是搭服务器，也许毕设就这个了~
2. 接口太没技术含量了，我想学其他更高级的！但是又怕连接口都没熟悉，写个毛啊？
3. 尽快通懂23种设计模式，我希望是工作3个月能完成。