数据库命名及书写规范(二)
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，建议使用绑定变量。
一定要及时关闭和释放游标。
建议在异常处理中，把收集到的错误信息记入错误日志表，以备查询和分析。