（转载）oracle开发规范

规则1: 数据库代码中，关键字大写，其他内容小写（在PL/SQL中可设置关键字自动转换为大写，以降低编码时的大小写切换）

规则2：程序块应采用缩进风格书写，保证代码可读，风格一致，缩进格数统一为2格；

规则3：代码中需要空位时，统一采用空格键输入，不允许用TAB键产生空位； 说明：不同的编辑器对TAB的空位格数设置不一致，会导致使用TAB键产生空位的代码格式混乱；

规则4：同一条语句占用多行时，每一行的开始应是关键字，且关键字应和第一行左对齐,如确实不能从关键字分行，则分行处应对其上一行被分行的同类代码的最左边；

建议1:对于INSERT… VALUES和UPDATE语句，一行写一个字段，每个字段相对于INSERT语句空两格，这段后面紧跟注释（注释语句左对齐），VALUES和INSERT左对齐，左括号和右括号与INSERT、VALUES左对齐。

建议2:INSERT…SELECT 语句时，应使每行的字段顺序对应，以每行最多不超过4 个字段，以方便代码阅读，括号的内容另起一行缩进2 格开始书写，关键字单词左对齐，左括号、右括号另起一行与左对齐。

规则1：不允许将多行语句书写在同一行;

规则2：不允许将SQL语句写成一行，再短的SQL也应该在谓词处分行 ;

规则3：相对独立的程序块之间应加空行

规则4：不同类型的操作符混合使用时，应使用括号明确的表达运算的先后关系;

规则5：BEGIN和END应独立成行

规则6：SQL语句中的逗号后面应增加一个空格，以使得代码清晰

建议1：减少控制语句的判断次数，比如在ELSE（IF…ELSE）语句中，尽量将尽快能检测到结果的判断提前

建议2：尽量避免使用嵌套的IF语句，在这种情况应使用多个IF语句来判断其可能性。

建议3：存储过程、函数、触发器、程序块中定义的变量和输入、输出参数在命名上有所区分。

一般用’v_’开头代表程序块中定义的变量

一般用’p_’开头代表输入参数变量

一般用’x_’开头代表输入输出或输出参数变量

规则1：查询数据时，尽量不使用SELECT *，而是给出明确的字段，但该规则不包括SELECT COUNT(*)语句

规则2：INSERT语句应该出字段列表

规则3：从表中同一笔记录中获取记录的字段值，须使用一SQL 语句得到，不允许分多条SQL 语句。

规则4：当一个PL/SQL 或SQL 语句中涉及到多个表时，始终使用别名来限定字段名，这使其它人阅读起来更方便，避免了含议模糊的引用，其中能够别名中清晰地判断出表名。

说明 ： 别名命名时，尽量避逸使用无意义的代号a、b 、c… ， 而应该有意义( 如表mtl_system_items_b 对应别名为msi，po_headers_all 别名对应为pha)。

规则5：确保变量和参数在类型和长度与表数据列类型和长度相匹配。

说明：如果与表数据列宽度不匹配，则当较宽或较大的数据传进来时会产生运行异常。

规则6：一句SQL如果只访问了单表，禁止使用表别名

规则7：运算符以及比较符左边或者右边只要不是链接的括弧，则空一格

规则8：任何SQL书写单行不得超过80字符（含左边的缩进）

规则9：无特殊情况，代码注释尽量使用英文；

所有命名规则中，必须优先遵守通用规则，列入通用规范中的规则必须强制遵守

规则1：任何数据库对象的命名，不得使用汉字；

规则2:任何命名长度不得超过30

说明：在部分数据库中（例如ORACLE），表名长度是不可以超过30的，如果命名超过30，则可能给以后的迁移带来麻烦

规则3：用户对象命名应全部为小写，且不允许使用控制符号强制转换对象为小写字符

说明：部分数据库（如oracle中，系统表会记录对象为大写，如果使用了强制转换为小写，则每次访问均要使用强制字符访问）

规则4：命名应使用富有意义的英文，禁止使用拼音首字母，一般情况下不建议使用拼音命名；

规范5：命名不得使用数据库保留字

说明：使用了数据库保留字，会导致需要访问该对象时，需要代码做特别的转换才能访问

规则1：同类业务的表，以相同的表示该类业务的英文开头.

说明：同类业务的表以相同的英文开头，在逻辑上清晰，且可避免维护过程中对该类表的误操作

如下语句不符合规范(假定表wap_user和表user_login_log都属于wap类业务)

CREATA TABLE wap.wap_user

CREATE TABLE wap.user_login_log

如下语句符合规范

CREATA TABLE wap.wap_user

CREATE TABLE wap.wap_user_login_log

规则2：同类表，如果按照时间不同建立的表，后缀格式一般情况下应为’_YYYY[MM[DD]]’格式

如下语句不符合规范（将年份2010简写为10，导致含义模糊）

CREATE TABLE wap.wap_user_login_1004

CREATE TABLE wap.wap_user_login_1005

如下语句符合规范

CREATE TABLE wap.wap_user_login_201004

CREATE TABLE wap.wap_user_login_201005

规则1：字段命名应具有含义，能反映该字段存储的内容，如确实无法使用富有含义的字段名，则应增加字段备注。

规则2：同种用途的字段，在同一个业务中的所有表中，应保持有同样的字段类型和字段长度，并尽量保持一致的字段命名,否则易导致业务接口冲突）

建议1：字符类型尽量定义为varchar类型而非char类型

说明：在数据库存储中，varchar类型采用变长存储，而char类型为定长存储，在大多数情况下，定长更浪费空间，但是定长字符的性能略高于变长字符

规则1：主键名称应以”pk_”开头，后接表名

规则1：外键名应以”fk_”开头,后接表名

规则1：唯一索引应以”uk_”+”表名_”+”字段名”命名

规则2：普通索引应以”idx_”+”表名_”+“字段名”命名

规则3：bitmap索引应以”bidx_”+”表名_”+“字段名”命名

规则1：视图命名应以“v_”+“表名[_表名[_表名]]”命名

规则1：同义词命名要求和其所指向的对象同名

规则1：函数命名以”func_”开头，后接函数的功能

规则1：存储过程以“prc_”开头，后接功能描述

规则1：包以“pkg_”开头，后接功能描述

规则1：数据库链以“dl_”+“$SID_$USER”命名

规则1：触发器以“tri_”+表名+“_ins/del/upd”+”_before/after”命名

规则1：物化视图以“mv_”+“表名[_表名]”命名

规则1：临时表以“tmp_”开头，后接功能描述

规则2：如果是在上线/割接中被重命名的表，命名应是原表名+“_YYYYMMDD”

规则1：数据库用户名以字母开头，字母和数字混合且长度不超过8个字符,同时，密码必须包含小写字母，大写字母，数字，特殊字符四种组合且不少于8位

如下语句不符合规范(用户名以数字开头且超过8位，密码只有小写字母且不足8位)

CREATE USER 12345guoyue identified by guoyue;

如下语句符合规范

CREATE USER guoyue IDENTIFIED BY Oracle123456&8(;

规则1：数据库设计文档中，必须包含表数据保留时间；

规则2：数据库设计文档中，必须包含表在最大保留时间下的数据量；

规则3：数据库设计文档中，如果表为分区表，必须包含分区条件；

规则4：数据库设计文档中，必须包含表的读写频率；

规则5：单SEGMENT （如单个普通表，分区表的单个分区，单个普通索引，分区索引的单个分区）原则上不得超过2GB大小；

规则6：和其他表有关联的表，和其他表功能一致的字段类型以及长度，尽量使用相同的列名；

规则7：禁止依靠设计数据库表之间的主外键关系来保证数据一致性；??

规则8：需要UPDATE的字段，不得设计为分区条件字段；

建议1：对于需要同步到数据仓库的表，原则上必须包含同步频率以及同步机制；

建议2：原则上每个表应设计一个主键；

建议3：原则上不建议使用大对象类型（CLOB,BLOB,LOGN）等类型字段，如需设计这些字段，需有特别说明；

建议4：如无特别需要，原则上，字符类型选择变长字段，数字类型选择NUMBER；

建议5：如无特别需要，原则上不得设定表的并发度，压缩等属性；

建议6：对于易混淆的字段，建议加上备注；

规则1：无特别说明，每个表的索引，不得超过5个；

规则2：单字段上的索引不得超过2个；（即一个单字段最多可在上面建立一个单字段索引和一个组合索引包含这个字段）

规则3：复合索引原则上不得超过3个字段；

规则4：原则上，分区表的索引必须是分区索引；

建议1：频繁出现在where字句里的字段建议建立索引；

建议2：用来和其他表关联的字段建议建立索引；

建议3：索引字段建议有高的选择性和过滤性（count(distinctid)/count(*)>0.6）；

建议4：对于枚举值较少的字段，建议不要创建B-tree索引，建议建立bitmap索引；

建议5：在where子句里作为函数参数的字段，不能创建索引，不建议建立函数索引;

建议6：建立索引的时候，建议考虑到SELECT和INSERT,UPDATE,DELETE的平衡；

建议7：一般建议在查询数据量10%以下使用索引；

建议8：WHERE子句的查询条件构成索引字段前导字段；

建议9：选择性更高的字段放在组合字段索引的前导字段；

建议10：如果字段选择性接近，则把频繁查询的字段放在前面；

建议11：如果字段查询频率相同，则把表中的数据的排列顺序所依据的字段放在前面；

建议12：进行GROUP BY或者是ORDER BY的字段应在组合字段索引的前导字段；

规则1：所有序列应设置CACHE值为不低于100

规则1：频繁更新的表上，不得建立refreshfastoncommit类型的物化视图

建议1：如非必要，不建议使用物化视图，可采用程序控制的表来进行数据的同步

规则1：视图中不允许出现ORDER BY排序

规则2：基于多表关联的视图，必须在字段名前指定表别名

建议1：视图的基础数据尽量从表中获取，尽量不要嵌套视图

规则1：存储过程，必须有异常捕获代码

规则2：存储过程中严禁使用GOTO语句进行跳转

规则3：有循环更新的存储过程，必须进行批量提交，且必须进行事物控制

规则4：存储过程中如果打开了dblink，则在存储过程正常或者异常退出必须关闭所有打开的dblink

规则5：存储过程中如果使用了游标，则在存储过程正常或者异常退出必须关闭所有打开的游标

规则6：存储过程中如果有更新，必须在异常捕获代码中做回退操作

建议1：存储过程每次被更新，应在注释中说明更新的内容，更新的日期，以及更新的责任人，并且在更新前保留旧版本代码

规则1：函数中，如果进行了事物处理，必须有异常捕获代码

建议2：函数尽量只是实现复杂的计算功能，不对数据库进行更新操作

规范1：如无必要，不得设计触发器，任何触发器的设计，必须得到DBA批准

规则1：当在SQL语句中连接多个表时, 请使用表的别名并把别名前缀于每个COLUMN上.这样一来,就可以减少解析的时间并减少那些由COLUMN歧义引起的语法错误.

规则2：禁止进行字段数据类型的隐式转换，所有转换必须进行明确的数据类型转换

说明：隐式转换会导致字段上的索引失效，而进行显式转换，会提醒到开发人员该种操作会导致索引失效

规则3：禁止在多表关联的时候，在非索引字段上的关联；

规则4：进行模糊查询时，禁止条件中字符串直接以“%”开头；

建议1：尽量使用DECODE来简化SQL访问数据库的次数

如下两个语句实现的功能

SELECT COUNT(*)，SUM(salary)

FROM hr.employees

WHERE = department_id = 20

AND first_name LIKE ‘SMITH%’;

SELECT COUNT(*)，SUM(salary)

FROM hr.employees

WHERE = department_id = 30

AND first_name LIKE ‘SMITH%’;

可以使用DECODE改写为如下语句

SELECT COUNT(DECODE(department_id,20,’*',NULL)) d20_count,

COUNT(DECODE(department_id,30,’*',NULL)) d30_count,

SUM(DECODE(department_id,20,salary,NULL)) d20_sal,

SUM(DECODE(department_id,30,salary,NULL)) d30_sal

FROM hr.employees

WHERE first_name LIKE ‘SMITH%’;

建议2：避免使用HAVING子句, HAVING 只会在检索出所有记录之后才对结果集进行过滤. 这个处理需要排序,总计等操作. 如果能通过WHERE子句限制记录的数目,那就能减少这方面的开销.

建议3：一次UPDATE多个字段的时候，应一次查询完成

建议4：使用EXISTS/NOT EXISTS替代IN/NOT IN