SQL语言艺术读书笔记
一、创建
（一） 关系理论的关键原理：关系不包含重复数据，且记录之间没有顺序
（二）实现3NF的步骤
1. 确保原子性（atomicity）
细节之中潜藏着危险，过分“精益求精”会使我们精力分散，甚至关注不相干的问题，合理把握处理数据的层次非常重要。
一般而言，应尽量使用具有实际意义的主键，而不是灰色的递增整数。
所有属性都具有了原子性，且确定了键，我们的数据就符合1NF了
2. 检查对键的完全依赖性
在1NF的基础上，如果去除了只依赖部分键的属性后，表就符合2NF了，如在保存用户信息时，单位，姓名都设置为字段，但同一个单位中的人员不止一个，那么在用户表中保存的单位字段就不完全依赖用户表的主键，这样会造成数据的冗余，可以把单位分离出来。
3. 检查属性的独立性
通常，满足2NF的数据集也满足3NF。我们可以这样思考：属性A的值确定之后，属性B的值是否就确定了呢？
4. 空值对程序逻辑是危险的，必须使用空值的话，一定要清楚它在特定情况下的影响
5. 子类型。
- 表过“宽”的另一个原因是对数据之间的关系了解不够深入。可以使用子类型。
- 给子类型表指定完全独立于父表主键的主键，是极其错误的，如果子类型主键不是父表主键的子集的话，在很多方面都会导致性能降低。
- 所有子类型表中的主键的交集必须为空，所有子类型表中的主键的并集是父表中的主键的集合。 这样是正确的方法。
- 开发者不应忘记数据库恢复后要进行所有功能性的检查，整个设计越复杂，开发者就越应记住操作数据时的诸多约束。
- 如果需要对字段使用函数，就意味着表中原子性的数据不符合业务需求。
二、查询
- 查询临时表的语句效率比永久表差。
- 将一次“大批量数据处理”分隔成多次“小块处理”是个坏主意。如一次批量导入和多次循环逐条导入。
- 尽可能多地把事情交给数据库优化器来处理，也就是说，要尽可能使用SQL解决问题，并尽可能利用每次数据库访问完成尽量多的工作。
- 不要把OO方法与关系数据库处理混为一谈，混淆关系和面向对象的概念以及将表等同于类、字段等同于属性、都是致命的错误。
- 没有必要编程实现那些数据库隐含实现的功能。
三、索引
- 对于通用目的或事务处理型数据库而言，大部分表不需要加索引，因为许多表的查找是根据一组非常有限的条件来进行的。
- 正如数据设计的初衷所规定的，索引是一种以原子粒度访问数据的手段，而不是为了检索大量数据的；否则，就严重误解了索引的作用。
- 你一定要非常清楚为哪些字段加索引，以及 为什么为它们加索引。
- 建立索引必须有理由，无论是对外键，或是其他字段，都是如此。很多情况下无需为外键建立索引。
- 正确使用系统生成键大有裨益，但切勿滥用。
- 索引不是万灵药，充分理解要处理的数据，做出合理的判断，才能获得高效方案。
四、SQL语句
- 关系理论姿于数据库，正如土木工程学之于桥梁。
- 关系操作负责找出我们要操作的数据集，而“非关系操作层”对有限的数据集进行“精雕细刻”，从而产生用户期望的结果。
- 排序，统计等操作属于非关系操作范畴。
- SQL用来表达“要做什么”，优化器来完成“如何来做”。
- 切记，关系理论的数据基础为数据处理提供了非常严谨的逻辑支持，因此SQL艺术本应该注重减小“非关系操作层”的厚度，即尽量在“关系操作层”完成大部分处理。
- 如果是若干个小查询，优化器将个个优化；如果是一个大的查询，优化器将它作为一个整体优化。
- 熟练的开发者应该努力使响应时间与返回的记录数成比例，这符合用户的预期。
- 当视图返回不必要的元素时，别把视图内嵌在查询中，而是应将视图分解，将其组成部分加到查询主体中。
- 高效定义过滤条件的准则是：尽快的减少必须处理的数据量。
- 在连接中指定过滤条件利于提高性能，如：
join orders o on o.custid = c.custid and a.ordered >= somefunc
- 避免在最高层使用distinct应该是一个基本原则，如要避免下面的方式
select distinct c.custname
from customers c,
orders o,
orderdetail od,
articles a
where c.city = 'dalian'
and c.custid = o.custid
and o.ordid = od.ordid
and od.artid = a.artid
and a.artname = 'aodi'
and o.ordered >= somefunc
