一 对象和字段的命名规范
1.1 命名的几种方式
|
UserPrivilege |
适合那些英文比较好，并且喜欢抑扬顿挫和有艺术美感的人 |
|
userprivilege |
适合那些英文好，且比较严谨的人，毕竟全部小写很容易与数据库关键字区别 |
|
tbl_user_privilege |
适合那些做开发的人，开发的人会习惯性地给变量加前缀 |
|
yhqx |
热爱中文的人，前提是恐怕你得对这些缩写先做好相关备注，等大家习惯了才行 |
图 1 命名规范表
实际上这几种命名规范各有千秋，很难去指责或否定哪种不好，完全取决于整个公司多数人的习惯，只有绝大多数人心甘情愿地去遵从了，那就是好的命名规范。
注意规则：
不建议使用数据库关键字和保留字（不建议并不意味着不能使用），只是为了避免不必要的冲突和麻烦。
例如，name,id,level,remark,description等。
如果有兴趣，则大家可以参考SELECT *FROM v$reserved_words WHERE reserved='Y'。
实际上Oracle 不建议大家使用v$reserved_words表中所有的关键字，因为这些关键字太多了；reserved='Y'的关键字则是被完全禁止的。
1.2 对象命名规范
用户自定义的数据库对象名包括表、视图、主外键、索引、触发器、函数、存储过程、序列等。
除数据库名长度为1-8个字符外，其余为1-30字符，命名只能用数据、字母、下划线表示。
下图为各对象命名规范表：
|
对象名 |
前缀 |
书写规范 |
|
表 （table ） |
tbl_/t_（或不加前缀） |
userinfo/t_user_info/ |
|
视图 （view） |
v_/v |
v_user_info/vuserinfo |
|
序列 （sequence） |
seq_ |
seq_user_info |
|
簇 （cluster） |
c_ |
c_user_info |
|
触发器（trigger ） |
trg_ |
trg_user_info |
|
存储过程（procedure ） |
sp_/p_ |
sp_user_info/p_user_info |
|
物化视图（materialized view ） |
mv_ |
mv_user_info |
|
函数（function） |
f_/fn_ |
fn_user_info/f_user_info |
|
包和包体（package & package body） |
pkg_ |
pkg_user_info |
|
类和类体(type & type body） |
typ_ |
typ_user_info |
|
主键 （primary key ） |
pk_ |
pk_user_info |
|
外键 （foreign key） |
fk |
fk_user_info_fieldname |
|
唯一索引（unique index ） |
uk_ |
uk_user_info_fieldname |
|
普通索引（normal index ） |
idx |
idx_user_info_fieldname |
|
同义词（synonym） |
依所分配的表所属模块 |
|
|
数据库链接（database link） |
无特殊要求 |
|
图2 对象命名规范表
1.3 变量命名
所有PL/SQL 中的变量与对象命名规则相似，如下表所示：
|
变量类型 |
前缀 |
范例 |
|
输入变量 |
i_/i |
i_user_id/iuserid |
|
输出变量 |
o_/o |
o_user_name/ousername |
|
输出输入变量 |
io_/io |
io_user_name/iousername |
|
普通变量 |
v_/v |
v_user_id/vuserid |
|
全局变量 |
gv_/gv |
gv_user_id/gvuserid |
|
常量 |
大写 |
PI |
|
游标 |
cur_ |
cur_userinfo |
|
用户自定义类型 |
type_ |
type_user_info |
图3 变量命名表
注意规则：
1. 命名不允许使用中文或者特殊字符。
2. 命名中若使用特殊约定或缩写，则要注释说明。
3. 使用有意义、易于记忆、描述性强、简短及唯一的英文单词/拼音缩写。保持自己特有的命名风格，不可来回变化。
说明：个人命名风格，在符合所在项目组的命名规则的前提下，才可以使用。对于变量命名，禁止取单个字符（如i、j „„），建议除了要有具体含义外，还要能表明变量类型等。
二 书写规范
2.1 注释规范
注释的书写体现了一个人思考问题的全过程和步骤，就算代码写得很差，只要注释写得好，至少也会给人以良好的感觉。注释的原则是有助于对程序阅读理解，语言需准确、易懂、简洁、精炼。
统一文件头的注释：
主要是对相关过程、函数进行功能性描述、修订记录，以及入参出参说明。
对存储过程、函数的任何修改，都需要在注释后添加修改人、修改日期及修改原因等修订说明。
/***********************************************************
名称: sp_xxx
功能描述：
修订记录：
版本号 编辑时间 编辑人 修改描述
1.0.0 2013-01-01 John 1. 创建此存储过程
1.0.1 2013-02-01 Sandy 2. 增加传入参数
入参出参描述：
iparameter1 IN VARCHAR2(20) 传入参数1
iparameter2 IN VARCHAR2(20) 传入参数2
iparameter1 OUT VARCHAR2(20) 传出参数1
iparameter2 OUT VARCHAR2(20) 传出参数2
返回值描述：(主要针对函数)
0 -Success
1 -normal fail
***********************************************************/
规则：
1. 注释内容要清晰、明了、含义准确，防止注释二义性。
2. 在代码的功能、意图层次上进行注释，提供有用、额外的信息。
3. 避免在一行代码或表达式的中间插入注释。
4. 尽量使用“--”进行注释；行尾注释需使用“--”。
对程序分支必须书写注释。
说明：这些语句往往是程序实现某一特定功能的关键，对于维护人员来说，良好的注释有助于更好地理解程序，有时甚至优于看设计文档。
在程序块的结束行右方加注释，以表明程序块结束。
注释应与其描述的代码相似，对代码的注释应放在其上方或右方 （对单条语句的注释）相近位置，不可放在下面。
注释要与所描述的内容进行同样的缩排。
注释上面的代码应空行隔开。
注释用中文书写。
2.2 语法规范
良好的语法规范有助于书写出高效、完备的PL/SQL程序，同时有助于提高系统的容错性、健壮性、可追溯性。
避免隐式的数据类型转换。
说明：在书写代码时，必须确定表的结构和表中各个字段的数据类型，特别是在书写查询条件时的字段就更要注意了。这个是导致SQL 性能不佳的原因之一。
为了方便不同数据库平台的移植，尽量使用SQL99标准，而不要使用Oracle 的“方言”。
例如，DECODE 函数完全可以用CASEWHEN 语句代替，而且可编程性更强。
(+)=右关联用RIGHT OUTER JOIN 语句代替。
=(+)左关联用LEFT OUTER JOIN 语句代替。
对于非常复杂的SQL （特别是多层嵌套、带子句或相关的查询），应该先考虑是否是由设计不当引起的，对于复杂的一些SQL 可以考虑使用程序实现，原则上遵循一句话只做一件事情。
关于处理的优先级。
1. 静态SQL>动态SQL。
2. 绑定变量的SQL>动态SQL （在OLTP 系统中建议这么做）。
3. SQL>PL/SQL 的过程，极端复杂的SQL 除外。
4. SQL>游标遍历。
5. Oracle 函数> 自定义函数。
6. 尽量使用Oracle 分析函数代替同一个表多次的关联。
原则上不要使用动态SQL，如果非得使用动态SQL，建议使用绑定变量。
一定要及时关闭和释放游标。
建议在异常处理中，把收集到的错误信息记入错误日志表，以备查询和分析。