PL/SQL最差实践

核心提示： 声明自己的异常处理机制，处理与业务相关的异常，PL/SQL最差实践(3)，将业务异常与系统运行期异常分开处理，自定义完整的异常信息，采用方法1编码的程序需要仔细查找每一段代码，容易产生错误，异常信息中包含异常发生时的场景，5. 固定的变量长度和变量类型 影响：可维护性症状：当声明基于字段类

声明自己的异常处理机制，处理与业务相关的异常，将业务异常与系统运行期异常分开处理。

自定义完整的异常信息，异常信息中包含异常发生时的场景。

5. 固定的变量长度和变量类型

影响：可维护性

症状：当声明基于字段类型的变量时，尤其是varchar2类型，直接使用固定长度声明。

为什么是最差：

这种硬编码的变量大小很可能与数据库中实际大小不符

如果字段的类型、大小等发生变化，还需要到PL/SQL中调整变量

解决之道：

使用%Type声明与字段类型相关的变量。

6. 不做单元测试

影响：健壮性

症状：PL/SQL代码中蕴含大量的业务逻辑，这些逻辑编写完毕后，没有提供合适的单元测试用例用于验证。

为什么是最差： 不做单元测试的危害这里就不再废话了。

解决之道：

PL/SQL并没有提供诸如JUnit之类易用的单元测试工具。现在有一些开源工具可以使用。使用utPLSQL(http://utplsql.sourceforge.net/)工具进行单元测试，或DBUnit进行二次开发，满足不同应用的需要。

7. 使用代码值而不使用代码名称

影响：可维护性

症状：我们看下面的代码：

方法1：

V_sex:=’1’; -- 男

方法2：

CONST_MALE CONSTANT VARchar2(1) := ’1’; -- 定义常量 男

V_sex:=CONST_MALE;

为什么是最差：

从例子中可以看出，同样是使用性别，方法1是直接使用代码值，方法2是使用常量，看上去似乎方法2要比方法1麻烦一些，但方法2比方法1更为直观，代码的可读性也更好，代码的阅读者不需要关注“1”代表什么含义。

当其他项目男性性别定义修改为“2”时，采用方法1编码的程序需要仔细查找每一段代码，容易产生错误，而采用方法2编码的程序只修改常量定义即可。