PL/SQL最差实践

核心提示： PROCEDURE 过程A(错误代码 out varchar2,错误信息 out varchar2) ISBEGIN...SAVEPOINT A;update T_A SET COL1 = 10;COMMIT;delete FROM T_A where COL1 = 20;ROLLBACK

　　PROCEDURE 过程A(错误代码 out varchar2,错误信息 out varchar2) IS
　　BEGIN
　　...
　　SAVEPOINT A;
　　update T_A SET COL1 = 10;
　　COMMIT;
　　delete FROM T_A where COL1 = 20;
　　ROLLBACK TO A;
　　...
　　EXCEPTION
　　WHEN OTHERS THEN
　　...
　　END;

为什么是最差：

这种行为是我认为最差实践中危害最大的一种。随处可见的事务控制代码会造成数据不一致，引发的问题难于跟踪和调试。

解决之道：

由调用者决定何时提交或回滚事务。

对于需要特殊事务管理的过程如记载日志，使用自治事务。

11. 不使用绑定变量

影响：性能

症状：直接使用值而不使用绑定变量进行查询。尤其是在拼写sql的程序中，这种情况更突出。

为什么是最差：

这是一个常见问题，当代码中大量充斥固定的代码值时，数据库引擎每次都需要重新解析，不能使用既有的执行计划。

解决之道：对于这种经常执行的语句，使用绑定变量而非实际参数值执行。

12. 慎用ROWNUM=1

影响：可维护性、数据一致性

症状：在读取数据时，有时只需要取一行，这时where条件中就会用到ROWNUM=1。

为什么是最差：

之所以将这个实践评成最差，是因为笔者在实际工作中曾经遇到过这类问题，跟踪和调试都很困难。ROWNUM本身的处理顺序是在ORDER BY 之前，所以当ROWNUM=1时产生的结果很可能是随机的。

解决之道：了解要查询数据的含义，使用其他条件限制结果集。

13. 灵活的动态SQL

影响：可维护性、性能

症状：execute IMMEDIATE ‘select A FROM TAB1’ INTO v_a;

为什么是最差：动态SQL失去了编译期检查能力，将发生问题的可能性推迟到运行期。动态SQL也不利于优化，因为只有在运行期才能得到完整的SQL语句。

解决之道：尽量避免使用动态SQL，对于易变的业务逻辑可以抽取到中间层实现。

14. 对ROWID进行访问

影响：数据一致性

症状：使用ROWID作为数据更新、删除的where条件

为什么是最差：

ROWID属于Oracle底层存储结构，会随着数据的迁移、导入、导出发生变化，而业务逻辑则不应依赖底层存储结构。

解决之道：使用主键进行数据操作。