2.4.2 表设计
2.4.2.1 逻辑段设计原则
2.4.2.1.1 Tablespace
每个表在创建时候，必须指定所在的表空间，不要采用默认表空间以防止表建立在系统表空间上导致性能问题。对于事务比较繁忙的数据表，必须存放在该表的专用表空间中。
2.4.2.1.2 Pctused
默认pctused导致数据库物理空间利用率非常低40%左右；对于update比较少或update不导致行增大的表，pctused可设置在60—85之间；对于update能够导致行增大的表，update设置在40—70之间
2.4.2.1.3 Initrans
对于需要并行查询或者在RAC数据库中需要并行处理的表，initrans设置为2的倍数，否则，不设该值。
2.4.2.1.4 Storage
2.4.2.1.4.1 Initial
尽量减少表数据段的extents数量，initial的大小尽量接近数据段的大小64K，128K，… ，1M，2M，4M，8M，16M ，…，等按2的倍数进行圆整。例如表或分区数据段大小为28M，则initial取32M。
2.4.2.1.4.2 Next
表或分区扩展extents的大小，按上述方法进行圆整。当表或分区数据段无法按Initial接近值进行圆整的情况下，其大小可以按 Initial+Next进行圆整。此时，必须设置Minextents=2。例如：表或分区数据段大小为150M，则Initial=128M；Next=32M，Minextents=2。
2.4.2.1.4.3 Minextents
该参数表示表创建时候Extents的初始数量，一般取1—2。
2.4.2.1.4.4 Pctincrease
表示每个扩展Extents的增长率，设置pctincrease=0能够获得较好的存储性能。
2.4.2.2 非凡表设计原则
2.4.2.2.1 分区表
对于数据量比较大的表，根据表数据的属性进行分区，以得到较好的性能。假如表按某些字段进行增长，则采用按字段值范围进行范围分区；假如表按某个字段的几个要害值进行分布，则采用列表分区；对于静态表，则采用hash分区或列表分区；在范围分区中，假如数据按某要害字段均衡分布，则采用子分区的复合分区方法。
2.4.2.2.2 聚蔟表
假如某几个静态表关系比较密切，则可以采用聚蔟表的方法。
2.4.2.3 完整性设计原则
2.4.2.3.1 主键约束
关联表的父表要求有主健，主健字段或组合字段必须满足非空属性和唯一性要求。对于数据量比较大的父表，要求指定索引段。
2.4.2.3.2 外键关联
对于关联两个表的字段，一般应该分别建立主键、外键。实际是否建立外键，根据对数据完整性的要求决定。为了提高性能，对于数据量比较大的标要求对外健建立索引。对于有要求级联删除属性的外键，必须指定on delete cascade 。
2.4.2.3.3 NULL值
对于字段能否null，应该在sql建表脚本中明确指明，不应使用缺省。由于NULL值在参加任何运算中，结果均为NULL。所以在应用程序中必须利用nvl()函数把可能为NULL值得字段或变量转换为非NULL的默认值。例如：NVL（sale,0）。
2.4.2.3.4 Check条件
对于字段有检查性约束，要求指定check规则。
2.4.2.3.5 触发器
触发器是一种非凡的存储过程，通过数据表的DML操作而触发执行，起作用是为确保数据的完整性和一致性不被破坏而创建，实现数据的完整约束。
触发器的before或after事务属性的选择时候，对表操作的事务属性必须与应用程序事务属性保持一致，以避免死锁发生。在大型导入表中，尽量避免使用触发器。
2.4.2.4 注释
表、字段等应该有中文名称注释，以及需要说明的内容。
2.4.3 索引设计
对于查询中需要作为查询条件的字段，可以考虑建立索引。最终根据性能的需要决定是否建立索引。对于复合索引，索引字段顺序比较要害，把查询频率比较高的字段排在索引组合的最前面。在分区表中，尽量采用local分区索引以方便分区维护。
除非时分区local索引，否则在创建索引段时候必须指定指定索引段的tablespace、storage属性，具体参考4.4.2.1内容。
2.4.4 视图设计
视图是虚拟的数据库表，在使用时要遵循以下原则：
从一个或多个库表中查询部分数据项；
为简化查询，将复杂的检索或字查询通过视图实现；
提高数据的安全性，只将需要查看的数据信息显示给权限有限的人员；
视图中假如嵌套使用视图，级数不得超过3级；
由于视图中只能固定条件或没有条件，所以对于数据量较大或随时间的推移逐渐增多的库表，不宜使用视图；可以采用实体化视图代替。
除非凡需要，避免类似Select * from [TableName] 而没有检索条件的视图；
视图中尽量避免出现数据排序的SQL语句。
2.4.5 包设计
存储过程、函数、外部游标必须在指定的数据包对象PACKAGE中实现。存储过程、函数的建立如同其它语言形式的编程过程，适合采用模块化设计方法；当具体算法改变时，只需要修改需要存储过程即可，不需要修改其它语言的源程序。当和数据库频繁交换数据是通过存储过程可以提高运行速度，由于只有被授权的用户才能执行存储过程，所以存储过程有利于提高系统的安全性。
存储过程、函数必须检索数据库表记录或数据库其他对象，甚至修改（执行Insert、Delete、Update、Drop、Create等操作）数据库信息。假如某项功能不需要和数据库打交道，则不得通过数据库存储过程或函数的方式实现。在函数中避免采用DML或DDL语句。
在数据包采用存储过程、函数重载的方法，简化数据包设计，提高代码效率。存储过程、函数必须有相应的出错处理功能。
2.4.6 安全性设计
4.4.6.1 治理默认用户
在生产环境中，必须严格治理sys和system用户，必须修改其默认密码，禁止用该用户建立数据库应用对象。删除或锁定数据库测试用户scott 。
2.4.6.2 数据库级用户权限设计
必须按照应用需求，设计不同的用户访问权限。包括应用系统治理用户，普通用户等，按照业务需求建立不同的应用角色。
用户访问另外的用户对象时，应该通过创建同义词对象synonym进行访问。
2.4.6.3 角色与权限
确定每个角色对数据库表的操作权限，如创建、检索、更新、删除等。每个角色拥有刚好能够完成任务的权限，不多也不少。在应用时再为用户分配角色，则每个用户的权限等于他所兼角色的权限之和。
2.4.6.4 应用级用户设计
应用级的用户帐号密码不能与数据库相同，防止用户直接操作数据库。用户只能用帐号登陆到应用软件，通过应用软件访问数据库，而没有其它途径操作数据库。
2.4.6.5 用户密码治理
用户帐号的密码必须进行加密处理，确保在任何地方的查询都不会出现密码的明文。
2.5 SQL编写
2.5.1 字符类型数据
SQL中的字符类型数据应该统一使用单引号。非凡对纯数字的字串，必须用单引号，否则会导致内部转换而引起性能问题或索引失效问题。利用trim(),lower()等函数格式化匹配条件。
2.5.2 复杂sql
对于非常复杂的sql(非凡是有多层嵌套，带子句或相关查询的)，应该先考虑是否设计不当引起的。对于一些复杂SQL可以考虑使用程序实现。
USER_TAB_COMMENTS 数据字典
Comment on 可加注解
2.5.3 高效性
2.5.3.1 避免In子句
使用In 或 not In子句时，非凡是当子句中有多个值时，且查询数据表数据较多时，速度会明显下降。可以采用连接查询或外连接查询来提高性能。
Char 比 varchar 查询时高询
在进行查询及建立索引时，char比varchar的效率要高，当然varchar在存储上比char要好
2.5.3.2 避免嵌套的Select子句
这个实际上是In子句的特例。
2.5.3.3 避免使用Select * 语句
假如不是必要取出所有数据，不要用*来代替，应给出字段列表，注：不含select count(*)。
2.5.3.4 避免不必要的排序
不必要的数据排序大大的降低系统性能。
2.5.4 健壮性
2.5.4.1 Insert语句
使用Insert语句一定要给出要插入值的字段列表，这样即使更改了表结构加了字段也不会影响现有系统的运行。
2.5.4.2 Count(*)、Count(*)、count(distinct id)的区别
Select count(*) from testtab
得到表testtab的记录数
select count(id) from testtab
得到表testtab id字段非空记录数
select count(distinct id) from testtab
得到表testtab id字段值非相同记录数
2.5.4.3 Not null 为字段类型性质的约束
本约束功能在后期无语法使期失效，可使用修改字段类型方式
alter table modify 字段名 类型 not null
alter table modify 字段名 类型
