02.SQL语言艺术读书笔记

SQL语言艺术读书笔记

一、创建

(一) 关系理论的关键原理:关系不包含重复数据,且记录之间没有顺序
(二)实现3NF的步骤
1. 确保原子性(atomicity)

细节之中潜藏着危险,过分“精益求精”会使我们精力分散,甚至关注不相干的问题,合理把握处理数据的层次非常重要。

一般而言,应尽量使用具有实际意义的主键,而不是灰色的递增整数。

所有属性都具有了原子性,且确定了键,我们的数据就符合1NF了

2. 检查对键的完全依赖性

在1NF的基础上,如果去除了只依赖部分键的属性后,表就符合2NF了,如在保存用户信息时,单位,姓名都设置为字段,但同一个单位中的人员不止一个,那么在用户表中保存的单位字段就不完全依赖用户表的主键,这样会造成数据的冗余,可以把单位分离出来。

3. 检查属性的独立性

通常,满足2NF的数据集也满足3NF。我们可以这样思考:属性A的值确定之后,属性B的值是否就确定了呢?

4. 空值对程序逻辑是危险的,必须使用空值的话,一定要清楚它在特定情况下的影响
5. 子类型。
  1. 表过“宽”的另一个原因是对数据之间的关系了解不够深入。可以使用子类型。
  2. 给子类型表指定完全独立于父表主键的主键,是极其错误的,如果子类型主键不是父表主键的子集的话,在很多方面都会导致性能降低。
  3. 所有子类型表中的主键的交集必须为空,所有子类型表中的主键的并集是父表中的主键的集合。 这样是正确的方法。
  4. 开发者不应忘记数据库恢复后要进行所有功能性的检查,整个设计越复杂,开发者就越应记住操作数据时的诸多约束。
  5. 如果需要对字段使用函数,就意味着表中原子性的数据不符合业务需求。

二、查询

  1. 查询临时表的语句效率比永久表差。
  2. 将一次“大批量数据处理”分隔成多次“小块处理”是个坏主意。如一次批量导入和多次循环逐条导入。
  3. 尽可能多地把事情交给数据库优化器来处理,也就是说,要尽可能使用SQL解决问题,并尽可能利用每次数据库访问完成尽量多的工作。
  4. 不要把OO方法与关系数据库处理混为一谈,混淆关系和面向对象的概念以及将表等同于类、字段等同于属性、都是致命的错误。
  5. 没有必要编程实现那些数据库隐含实现的功能。

三、索引

  1. 对于通用目的或事务处理型数据库而言,大部分表不需要加索引,因为许多表的查找是根据一组非常有限的条件来进行的。
  2. 正如数据设计的初衷所规定的,索引是一种以原子粒度访问数据的手段,而不是为了检索大量数据的;否则,就严重误解了索引的作用。
  3. 你一定要非常清楚为哪些字段加索引,以及 为什么为它们加索引。
  4. 建立索引必须有理由,无论是对外键,或是其他字段,都是如此。很多情况下无需为外键建立索引。
  5. 正确使用系统生成键大有裨益,但切勿滥用。
  6. 索引不是万灵药,充分理解要处理的数据,做出合理的判断,才能获得高效方案。

四、SQL语句

  1. 关系理论姿于数据库,正如土木工程学之于桥梁。
  2. 关系操作负责找出我们要操作的数据集,而“非关系操作层”对有限的数据集进行“精雕细刻”,从而产生用户期望的结果。
  3. 排序,统计等操作属于非关系操作范畴。
  4. SQL用来表达“要做什么”,优化器来完成“如何来做”。
  5. 切记,关系理论的数据基础为数据处理提供了非常严谨的逻辑支持,因此SQL艺术本应该注重减小“非关系操作层”的厚度,即尽量在“关系操作层”完成大部分处理。
  6. 如果是若干个小查询,优化器将个个优化;如果是一个大的查询,优化器将它作为一个整体优化。
  7. 熟练的开发者应该努力使响应时间与返回的记录数成比例,这符合用户的预期。
  8. 当视图返回不必要的元素时,别把视图内嵌在查询中,而是应将视图分解,将其组成部分加到查询主体中。
  9. 高效定义过滤条件的准则是:尽快的减少必须处理的数据量。
  10. 在连接中指定过滤条件利于提高性能,如:
join orders o on o.custid = c.custid and a.ordered >= somefunc
  1. 避免在最高层使用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

推荐阅读更多精彩内容