数据库设计规范

1 命名约定
1.1 语言
命名应该使用英文单词，避免使用拼音，特别不应该使用拼音简写。命名不允许使用中文或者特殊字符。英文单词使用用对象本身意义相对或相近的单词。选择最简单或最通用的单词。不能使用毫不相干的单词来命名当一个单词不能表达对象含义时，用词组组合，如果组合太长时，采用用简或缩写，缩写要基本能表达原单词的意义。当出现对象名重名时，是不同类型对象时，加类型前缀或后缀以示区别。
1.2 大小写
名称一律大写，以方便不同数据库移植，以及避免程序调用问题。
1.3 单词分隔
命名的各单词之间可以使用下划线进行分隔。
1.4 保留字
命名不允许使用SQL保留字。
1.5 命名长度
表名、字段名、视图名长度应限制在20个字符内(含前缀)。
1.6 字段名称
同一个字段名在一个数据库中只能代表一个意思。比如TELEPHONE在一个表中代表“电话号码”的意思，在另外一个表中就不能代表“手机号码”的意思。不同的表用于相同内容的字段应该采用同样的名称，字段类型定义。
2 数据对象
2.1 表属性
2.1.1 表名
前缀为TBL_。数据表名称必须以有特征含义的单词或缩写组成，中间可以用“_”分隔，例如：TBL_PSTN_DETAIL。表名不能用双引号包含。
2.1.2 表分区名
前缀为P。分区名必须有特定含义的单词或字串。例如：表TBL_PSTN_DETAIL的分区P2004100101表示该分区存储2004100101时段的数据。
2.1.3 字段名
字段名称必须用字母开头，采用有特征含义的单词或缩写，不能用双引号包含。
2.2 索引
2.2.1 普通索引
前缀为IDX_。索引名称应是前缀+表名+序号，例如：IDX_PSTN_DETAIL1。
注：表名不含TBL_前缀。
2.2.2 主键索引
前缀为IDX_PK_。索引名称应是前缀+表名，例如：IDX_PK_PSTN_DETAIL。在创建表时候用USING INDEX指定主键索引属性。
2.2.3 唯一索引
前缀为IDX_UK_。索引名称应是前缀+表名+序号，例如：IDX_UK_PSTN_DETAIL1。
2.3 视图
前缀为VIW_。按业务操作命名视图。
2.4 触发器
前缀为TRIG_。触发器名应是前缀+表名+触发器名。
2.5 序列
前缀为SEQ_。按业务属性命名。
2.6 表空间
前缀为TBS_。根据存储的特性命名，例如：TBS_PARAMETER。
3 数据类型
3.1 字符型
固定长度的字串类型采用char，长度不固定的字串类型采用varchar。避免在长度不固定的情况下采用char类型。如果在数据迁移等出现以上情况，则必须使用trim()函数截去字串后的空格。
3.2 数字型
数字型字段尽量采用number类型。
3.3 日期和时间
3.3.1 外部时间
由数据导入或外部应用程序产生的日期时间类型采用VARCHAR类型，数据格式采用：YYYYMMDDHH24MISS。
3.4 大字段
如无特别需要，避免使用大字段(BLOB/CLOB/LONG/TEXT/IMAGE等)。
3.5 唯一键
对于数字型唯一键值，尽可能用系列SEQUENCE产生。
4 设计
4.1 范式
如无性能上的必须原因，应该使用关系数据库理论，达到较高的范式，避免数据冗余,但是如果在数据量上与性能上无特别要求，考虑到实现的方便性可以有适当的数据冗余，但基本上要达到3NF.如非确实必要，避免一个字段中存储多个标志的做法。如11101表示5个标志的一种取值。这往往是增加复杂度，降低性能的地方。
4.2 表设计
4.2.1 逻辑段设计原则
每个表在创建时候，必须指定所在的表空间，不要采用默认表空间以防止表建立在系统表空间上导致性能问题。对于事务比较繁忙的数据表，必须存放在该表的专用表空间中。
4.2.2 特殊表设计原则
对于数据量比较大的表，根据表数据的属性进行分区，以得到较好的性能。如果表按某些字段进行增长，则采用按字段值范围进行范围分区；如果表按某个字段的几个关键值进行分布，则采用列表分区；对于静态表，则采用hash分区或列表分区；在范围分区中，如果数据按某关键字段均衡分布，则采用子分区的复合分区方法。
4.2.3 完整性设计原则
触发器是一种特殊的存储过程，通过数据表的DML操作而触发执行，起作用是为确保数据的完整性和一致性不被破坏而创建，实现数据的完整约束。触发器的before或after事务属性的选择时候，对表操作的事务属性必须与应用程序事务属性保持一致，以避免死锁发生。在大型导入表中，尽量避免使用触发器。
4.2.4 注释
表、字段等应该有中文名称注释，以及需要说明的内容。
4.3 索引设计
对于查询中需要作为查询条件的字段，可以考虑建立索引。最终根据性能的需要决定是否建立索引。对于复合索引，索引字段顺序比较关键，把查询频率比较高的字段排在索引组合的最前面。在分区表中，尽量采用local分区索引以方便分区维护。除非时分区local索引，否则在创建索引段时候必须指定指定索引段的tablespace、storage属性，具体参考4.2.1内容。
4.4 视图设计
视图是虚拟的数据库表，在使用时要遵循以下原则：从一个或多个库表中查询部分数据项；为简化查询，将复杂的检索或字查询通过视图实现；提高数据的安全性，只将需要查看的数据信息显示给权限有限的人员；视图中如果嵌套使用视图，级数不得超过3级；由于视图中只能固定条件或没有条件，所以对于数据量较大或随时间的推移逐渐增多的库表，不宜使用视图；可以采用实体化视图代替。除特殊需要，避免类似SELECT * FROM [TableName]而没有检索条件的视图；视图中尽量避免出现数据排序的SQL语句。
5 SQL编写
5.1 字符类型数据
SQL中的字符类型数据应该统一使用单引号。特别对纯数字的字串，必须用单引号，否则会导致内部转换而引起性能问题或索引失效问题。利用TRIM()，LOWER()等函数格式化匹配条件。
5.2 复杂SQL
对于非常复杂的SQL(特别是有多层嵌套，带子句或相关查询的)，应该先考虑是否设计不当引起的。对于一些复杂SQL可以考虑使用程序实现。USER_TAB_COMMENTS数据字典COMMENT ON可加注解
5.3 高效性
5.3.1 避免IN子句
使用IN或NOT IN子句时，特别是当子句中有多个值时，且查询数据表数据较多时，速度会明显下降。可以采用连接查询或外连接查询来提高性能。CHAR比VARCHAR查询时高询在进行查询及建立索引时，CHAR比VARCHAR的效率要高，当然VARCHAR在存储上比CHAR要好
5.3.2 避免嵌套的SELECT子句
这个实际上是IN子句的特例。
5.3.3 避免使用SELECT *语句
如果不是必要取出所有数据，不要用来代替，应给出字段列表，注：不含SELECT COUNT()。
5.3.4 避免不必要的排序
不必要的数据排序大大的降低系统性能。
5.4 健壮性
5.4.1 INSERT语句
使用INSERT语句一定要给出要插入值的字段列表，这样即使更改了表结构加了字段也不会影响现有系统的运行。
5.4.2 COUNT(*)/COUNT(ID)/COUNT(DISTINCT ID)的区别
SELECT COUNT(*) FROM TBL_TEST得到表TBL_TEST的记录数；
SELECT COUNT(ID)FROM TBL_TEST得到表TBL_TEST ID字段非空记录数；
SELECT COUNT(DISTINCT ID) FROM TBL_TEST得到表TBL_TEST ID字段值非相同记录数。
5.4.3 WHERE条件
无论在使用SELECT，还是使用破坏力极大的UPDATE和DELETE语句时，一定要检查WHERE条件判断的完整性，不要在运行时出现数据的重大丢失。如果不确定，最好先用SELECT语句带上相同条件来果一下结果集，来检验条件是否正确。