PL-SQL最差实践.docVIP

　　PL/SQL最差实践教育资源库 　　1. 超长的PL/SQL代码 　　影响：可维护性，性能 　　症状： 　　在复杂的企业应用中，存在动辄成百上千行的存储过程或上万行的包。 　　为什么是最差： 　　太长的PL/SQL代码不利于阅读，第三方工具在调试时也会出现代码行混乱等问题。PL/SQL存储对象（存储过程、包、函数、触发器等）行数上限约为6000000行，但实际工作中，当包大小超过5000行就会出现调试问题。 　　解决之道： 　　PL/SQL代码在执行前会被加载到shared pool中，shared pool以字节为单位，UNIX下为64K，桌面环境下为32K，可以通过查询数据字典USER_OBJECT_SIZE的PARSED_SIZE字段查看对象大小。对于较大的包，应采用拆包策略，抽取复用部分，减少重复代码；对于较大的存储过程，应将存储过程组织到包中，易于管理；对于较大的匿名块，应将匿名块重新定义成子过程保存在数据库中。 　　2. 脱离控制的全局变量 　　影响：可维护性 　　症状：在包中使用了全局变量，在多个位置对全局变量进行操作。 　　create OR REPLACE PACKAGE BODY PKG_TEST IS 　　GN_全局变量 NUMBER(12, 2); 　　PROCEDURE 过程A IS 　　BEGIN 　　GN_全局变量:=1; 　　END; 　　PROCEDURE 过程B IS 　　BEGIN 　　GN_全局变量:=2; -- 这里对全局变量进行了另外的操作 　　END; 　　为什么是最差： 　　全局变量可以在整个包范围内被访问到，因此对全局变量的跟踪和调试会比较困难。如果变量是在package中定义的，变量还可以被其他包访问，这将会更为危险。 　　解决之道： 　　减少或取缔全局变量的使用，对于要在过程间交互的变量，通过参数传递来实现。如果必须使用全局变量，应对全局变量进行get/set函数封装，规范对全局变量的访问。 　　3. PL/SQL中嵌入复杂SQL语句 　　影响：可维护性 　　症状： 　　在PL/SQL代码中嵌入SQL语句，如： 　　... 　　PROCEDURE 过程A IS 　　BEGIN 　　update T_A SET COL1 = 10; 　　END; 　　PROCEDURE 过程B IS 　　BEGIN 　　delete FROM T_A T_A T_A ALE CONSTANT VARchar2(1) := 1; -- 定义常量 男 　　V_sex:=CONST_MAL 12下一页 这篇文章来自..，。E; 　　为什么是最差： 　　从例子中可以看出，同样是使用性别，方法1是直接使用代码值，方法2是使用常量，看上去似乎方法2要比方法1麻烦一些，但方法2比方法1更为直观，代码的可读性也更好，代码的阅读者不需要关注1代表什么含义。 　　当其他项目男性性别定义修改为2时，采用方法1编码的程序需要仔细查找每一段代码，容易产生错误，而采用方法2编码的程序只修改常量定义即可。 　　解决之道： 　　将常量定义放入到公共的代码包中，供其他程序共享，所有涉及到代码值的比较、引用等都必须使用常量名，而不能直接书写代码值。对于一些复杂的代码值间的关系可以进一步封装，以函数的方式提供调用。 　　8. 不对PL/SQL对象进行配置管理 　　影响：可维护性 　　症状：PL/SQL对象（package、package body、trigger、procedure、type、type body、函数等）的代码没有使用配置管理工具进行维护和更新。 　　为什么是最差： 　　因为Oracle内部结构的差异，对象的管理具有一定的难度，尤其是在并行开发的情况下。 　　对象职责划分不清，造成多人同时修改一个对象，在编译时，如果后来者没有获取最新的代码，会造成前一个开发人员修改的代码被覆盖。 　　Oracle对象不能追溯既往，数据库中只能保存最新 　　解决之道： 　　规范开发过程，以配置管理工具上的PL/SQL代码为最新。 　　使用第三方插件减少同步工作量，如PL/SQL Developer下的VCS版本控制插件。 　　9. IF ELSE 的坏味道 　　影响：可维护性 　　症状：大量使用IF ELSE 　　为什么是最差： 　　大量存在IF/ELSE，造成代码逻辑混乱、不易修改。无论是PL/SQL还是其他编程语言，这种代码都已经飘着bad smell了。 　　解决之道： 　　使用Oracle数据库的继承特性，通过type实现对象的继承，利用策略模式封装差异，对外提供统一的调用接口