《Oracle性能优化谋生指南》-第四章：数据库逻辑设计和物理设计-学习小结-1
日期：2014-05-16 浏览次数：20409 次
《Oracle性能优化求生指南》-第四章：数据库逻辑设计和物理设计-学习小结-1
1、建立逻辑数据模型为第一阶段，包括对应用程序需要处理和存储的信息进行建模，并确保所有必要的数据都能够正确、完整且无歧义地表示。在关系数据库的实现中，这通常是指构造一个标准化的实体-关系(E-R)模型。
2、将逻辑数据模型映射为物理数据模型为第二阶段。对关系数据库来讲，物理数据模型描述的是表、索引、视图、键和其他一些数据库特性。
3、第三范式：
实体(表)的所有数据完全依赖于主键。
不能有重复的属性(列)或属性组。
不存在仅依赖部分主键的实体数据。
不存在依赖于其他非主键的实体数据。
用一条格言描述：”键，完整的键，除了键没有其他东西。“
4、无论从文档或定义角度看，逻辑模型中精确定义属性的数据类型、长度、精度都有优势。由于Oracle在数据类型的物理存储上采用的是通用且灵活性很强的内部实现方式，因此从存储或性能角度看，使用限制性很强的数据类型或精度并没有优势。
5、不管如何限制数据类型，大部分情况下，Oracle内部都会使用大范围高精度的浮点方式进行存储。
6、固定长度类型的字符串都会占用一个固定长度的存储空间，而不管字符串的真实长度是多少。采用固定的航长度可以降低碎片，但是它会导致较大的平均行长，这样就会增加全表扫描的开销。因此，除非数据的长度确实是固定的，否则就应该优先选择变长字符串类型(VARCHAR)。
7、人造键：
是由Oracle sequence产生的一个数字类型的列。
没有任何含义，只是为了唯一地标识实体中的记录。
从来不会被更新。
自然键：
可由多列组成并可包括任何数据类型。是由实体中具有唯一性的自然属性构成的。
如果自然键被更新，则引用它的外键也需要更新，这将显著增加IO开销和锁争用。
显然，必须基于自然键的列进行索引查询的需求也是很常见的，为满足这种需求，可以在这些列上创建普通索引或唯一约束。
8、逻辑阶段的主要目的是确保设计能够满足应用的功能需求。物理设计阶段的目的才是确保数据库能够满足应用的性能需求。将逻辑自雷转化为表的时候，要避免采用分开的父类表和子类表的方法，而要选择将所有子类映射为一个表，或采用单独的子类表而没有上一级表的方式。
9、表的类型有堆表、索引组织表、聚簇等。
散列聚簇(Hash Cluster)：能够有效优化大小相对固定的表的主键查询，与B*树索引相比，散列聚簇还能降低热点块上的闩锁争用。
索引聚簇(Index Cluster)：共享聚簇键值的多个表中的记录存储在一起，这样可以优化多表联结。虽然多表联结性增强了，但仅针对聚簇中某个表的全表扫描的性能却降低了。
嵌套表(Nested Table)：能够针对主表中的某一行优化对明细行的检索。但是，如果要跳过主表行检索明细行的话，性能通常会大打折扣。
索引组织表：如果大部分表访问都是通过主键进行查询，并且表数据量的变动幅度较大而不适合使用散列聚簇，使用索引组织表将会更高效。
对象表(Object Table)：行都被定义为一个Oracle对象数据类型，需要使用对象表的场景非常少。
10、精度的意义更多在于约束数据或定义文档，而不是为了优化性能。但是，如果一个高精度的数值被偶然指定给一个精度限制较弱的数字字段，这时候设定一个精度就可能对性能有所帮助。例如NUMBER(*,2)那么不必要的精度将会被截断，行的长度也将相应地减少。设置该数值列的精度有时可以减少行的长度。
11、DATE可以精确到秒，TIMESTAMP可以亚秒级，可以配置到纳秒级的精度，其默认精度则为微秒。
12、字符串若小于4000字节，优先选择VARCHAR2类型。
字符串若大于4000字节，推荐使
免责声明： 本文仅代表作者个人观点，与爱易网无关。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请读者仅作参考，并请自行核实相关内容。
