Oracle程序开发小技巧(一)
Oracle有许多的优点,但是如果使用不当,同样也不能发挥出它的强大优势,下面就本人在Oracle开发过程中积累的一点小经验,和大家做一个分享。
一、 数据库设计中字段的使用
在一些表的设计中,有一些常用的这段,已经基本成为一个规范,在大型系统中,多可以看到这些字段的踪影,当然字段的名字可能有所不同。常用的字段分为以下几类:
1.WHO字段
这类字段多用于记录每行记录的操作变更信息,比如是谁添加的这行记录,谁做过修改等,详细说明如下:
字段名称 |
类型 |
说明 |
LAST_UPDATE_DATE |
DATE |
最后修改日期 |
LAST_UPDATED_BY |
NUMBER(15) |
最后修改人 |
CREATION_DATE |
DATE |
创建日期 |
CREATED_BY |
NUMBER(15) |
创建人 |
I.创建人
在任何一个系统中,一般都会有一个权限验证和登录的过程,在登录后,会在系统的内存中记录登录人的信息,当此人在对数据库的某个表进行添加操作的时候,会同时把这个操作人员的ID值写入表中,供后期统计及审计
II.创建时间
与创建人的含义类似,在创建的同时,写入系统的当前时间,这个字段的值一般取自于服务器而不是客户端,比如在oracle中,可以直接使用SYSDATE作为这个字段的值
III.最后修改人
一条记录被创建后,同样会有被修改的可能性,这里需要对修改的人进行一个记录,以便于后期审计。
但是这里要注意的是,这里只记录最后的修改信息,如果一条记录经过多次的修改,中间的修改将无迹可寻,如果需要记录详细修改信息,需要使用日志功能,已经超出此字段的功效。
IV.最后修改日期
与最后修改人同时写入记录中,同理,也是记录最后一次修改的时间,中间的修改均被最后一次覆盖。
2. 状态及有效期字段
在一些新闻类的内容中,经常会涉及到一个时效性,即一条新闻可能只在某一个时间段内是对外可见的,超过这个时间段则将不允许发布,还有就是有些时候如果发现某些内容有问题,需要暂时对外屏蔽的时候,就可以用到状态字段,详细说明如下:
字段名称 |
类型 |
说明 |
STATUS |
NUMBER |
状态 |
START_DATE |
DATE |
有效开始日期 |
END_DATE |
DATE |
有效结束日期 |
I.状态
这个字段一般用数值型表达,0表示失效,1表示有效,当然在使用的时候,可以把这两个值进行转义,用“有效”和“失效”来显示,不影响存储方式。
失效不等于删除,经过失效的内容,经过管理程序的调整,把状态变成有效后,还可以恢复正常使用。
II.有效开始日期
这个字段如果填有具体的值,只有当时间超过这个时间后,信息才是有效的,在这个日期之前,信息将自动按无效处理,特别需要注意的是,如果这个字段置空,应该按跳过这个条件检查来处理,这样可以实现程序的灵活性。
III.有效结束日期
具体含义同上,只是超过此期,内容将按失效处理。
3.逻辑删除
在数据库系统中处理的删除的做法一般有两种:物理删除和逻辑删除,所谓物理删除,就是在数据库中直接使用delete等命令,从数据库里把数据真正的删除,这种删除从正常途径将无法恢复数据,虽然可以部分程度减小整体的数据量,但不利于审计跟踪;逻辑删除指的是对数据不做任何删除处理,而是对记录打个标记,也就是在某个字段上赋值,表示此记录已经删除。
逻辑删除的处理逻辑只由应用程序自己使用,因为数据在数据库中实际还是存在的。
所涉及字段如下:
字段名称 |
类型 |
说明 |
DELETED |
NUMBER |
是否删除 |
DELETE_DATE |
DATE |
删除时间 |
DELETED_BY |
NUMBER |
删除人 |
I. 删除标志
此字段有两个取值,0表示正常,1表示已经删除。
打上删除标志后,所以的查询语句必须同时在判断条件的地方加上deleted=0的条件,否则会造成重大的失误。
II. 删除时间
与删除标志一起使用,表示删除的时间,可以使用当前服务器的时间,用sysdate来填充即可。
III. 删除人
与最后修改人类似,需要记录删除的具体操作人员
删除与标志位不同,采用标志位的方式,虽然前端无法展示数据,但是后台管理人员人一样可以通过管理程序来调整该状态,但是删除标志则不同,确认删除后,对整个应该来讲,这条记录都应该理解为不存在了。
4. 自增字段
所谓自增字段,是指随着使用,它可以自动增加的字段。
这种字段的值一般没有明确的含义,只用于一个唯一标识,这个字段一般也会设置成主键。
如果应用只针对Oracle,而不考虑数据库无关性,那么sequence无非是最好的一个选择。对于以前用习惯MSSQL等其它数据库的朋友来说,Oracle这种用法简直是太费劲了,要花很大的功夫才能做好一个自增字段,但是正因为如此,它也带来了其它数据库不能相比的优点,举例来说,一个订单系统,即有订单头,又有订单行,一般是先插入订单头,再插入订单行,对于MSSQL等数据库的自增字段,只有插入后才知道具体的ID值是多少,那么写入后,还要返查一下这个字段值再给订单行使用;而对于oracle来说,只要先从sequence里取出一个值来,头和行一起使用即可,最主要是的sequence的效果是非常高的,不需要担心性能问题。
5. 弹性字段
在数据库表结构设计的时候,最好多留出几个备用的字段来,因为随着系统的使用,一般会有增加字段的需求。预留字段的好处是,只要需要的时候启用即可,不需要进行DDL操作,对数据库后期维护的风险很低,并且一般的DDL操作,会造成级联的VIEW/PACKAGE等程序失效,预留了弹性字段,则不会有这个问题。
预留的字段也可以按类型分成三种:字符串型,数值型及日期型,可以每个类型预留10个,或根据需要来决定,可以采用如下的样式:
NUMBER_ATTRIBUTE1
STRING_ATTRIBUTE1
DATE_ATTRIBUTE1
弹性字段如果不启用,会不会占用过多的存储空间呢,答案是否定的,因为在这种大型数据库的结构中,只有一个字段真正被用到的时候,才会去占用实际的空间,否则它只是一个“说明”,并不占用实际的空间,所以不会造成空间浪费。
6. 拆分字段
这并不是一个字段的类型,而是指在表设计的时候,可以适当的把一个大表拆成不同的小表来存储,比如用户表,可以包括登录名,密码,姓名,生日,等一系列的字段,在某些情况下,包括的会员属性可能达到上百个之多。
在数据量小的时候,无论怎么样的存储,都不会有性能问题,但是当数据量比较大的时候,就必须考虑性能问题。如果索引比较合理,不管数据量多大,一般查询速度都不会太慢,但是当某些特别情况,不能使用索引的时候,就会产生FTS(所谓的全表扫描),那么扫描一个小表和扫描一个大表所占的时间就完全不一样了,所以建议比较大的表分开存储,把常用的几个字段单独提取出来,这样即便全表扫描,也能比较好的控制效率。
在使用的时候,只要主表和子表都有索引,把它们联合起来查询,和一个真正的大表的效果基本上是一样的,虽然性能肯定比一个真实的大表慢一点,但是和另一方面的性能提升比较起来,是值得的。
目前有些大的系统采用这种拆分方式
二、 合理使用视图
视图是对基表的一个展现形式,它并不在物理上存储数据,只是在需要的时候去基表中调用数据,可以理解为把一个SQL封装起来方便使用的工具。
视图的优点有很多:
1. 方便性
如果一个查询很复杂,在程序中引用的时候,会非常不方便,特别是一个程序中反复调用这个SQL的时候,会使用程序显的非常臃肿,如果把SQL封装成视图,则会使整个程序显得非常清爽干净。
2. 灵活性
当一个表被多个程序引用的时候,如果表的结构发生变化,那么所有的程序都需要去做相应的调整,工作量非常大,而如果此时程序中只引用的是一个视图的话,我们只需要对该视图进行正确的修改,则所有的程序都不会有任何问题了。
3. 安全性
视图可以仅包括一个基表的有限几个字段,这样在公开权限的时候,使用该视图的用户,就能查看基表的其它保密字段了。
视图的优点比较多,建议在实际工作中多用视图。
三、 PACKAGE
PACKAGE即程序包,它的特点是可以在一个包中同时包括变量、函数及存储过程,并且在整个包内,所有的公共变量可以共享,这点是它最方便的地方。
包还有一个特点是对外接口变得更简单,不管包内部如何复杂,只要对外开放有限的接口即可。
包的这些特点在任何文档中都可以找到,不再多说,这里只强调一点,是关于包的失效,在aspx的程序引用oracle的package的时候,因为系统缓存的原因,它会记录package的失效状态,如果一个package的状态已经从失效重新编译为有效,那么IIS的cache记录的状态有可能不会自动更新,仍然按失效处理,这时就会造成系统的错误。为了避免这种错误的发生,我一般在package里加一个公共函数,取名为STATUS,此函数仅仅简单的返回一个数字1,在调用package其它函数之前,先调用这个函数来检查package的当前状态,如果能正确返回1,则可以继续后面的操作,如果返回为空,则表示当前package有问题,可以有一个交互来提示用户进行处理。当您的一个事务处理需要多个package协调处理的时候,如果前面的package已经处理成功,而后面的不能通过的时候,是一件很痛苦的事情,因为可能造成事务的不完整性,所以这时最需要提前检查一下所有的package的状态,把所有可能存在的危险都提前排除掉。
四、 索引
索引的作用很明显,可以大大的提高检查的速度,特别是对于大表来说,如果没有索引,就会需要全表扫描,这是一个非常占用时间的动作,所以需要建立相应的索引来提速。
但是在有些时候,索引会带来负面的影响,比如大量的插入或修改删除操作等,因为每个小的动作都会同时连带修改索引,会大大降低DML操作的效率,因此,在大量的DML操作之前,建议先把索引删除,操作完成后,重新建立索引,从总的时间上来讲,可以节约很多。
李鸣(aicken)原创 转载注明