oracle数据库：开发成功的Oracle应用_笔记12

1.3.4数据库独立性(续)

4.特性和功能

不必努力争取数据库独立性，这还有一个很自然的理由：你应当准确地知道特定数据库提供什么，并充分加以利用。

你当然可以编写你自己的复制，这么做可能很有意思，但是从最后看来，自己编写可能不是最明智的做法。数据库做了很多工作。一般来说，数据库会比我们自己做得更好。例如，Oracle中复制是用C编写的，充分考虑到了国际化。不仅速度快、相当容易，而且很健壮。它允许跨版本和跨平台，并且提供了强大的技术支持，所以倘若遇到问题，Oracle Support会很乐意提供帮助。如果要升级，也会同步地提供复制支持，可能还会增加一些新的特性。下面考虑一下如果由你自己来开发会怎么样。你必须为每一个版本都提供支持。老版本和新版本之间的互操作性谁来负责?这个任务会落在你的头上。如果出了“问题”，没有办法寻求支持，至少在得到一个足够小的测试用例之前，没有人来帮助你。当新版本的Oracle推出时，也要由你自己将复制代码移植到这个新版本。

5.要知道要哪些功能

如果没有充分地了解数据库已经提供了哪些功能，从长远看，其坏影响还会几次三番地出现。

最终目标不是对中间层调优，而是尽快地把中间层去掉。

???有另一个例子，许多人在Oracle数据库中建立后台进程从管道(一种数据库IPC机制)读消息。这些后台进程执行管道消息中包含的SQL，并提交工作。这样做是为了在事务中执行审计，即使更大的事务(父事务)回gun了，这个事务(子事务)也不会回gun。通常，如果使用触发器之类的工具来审计对某数据的访问，但是后来有一条语句失败，那么所有工作都会回gun。所以，通过向另一个进程发送消息，就可以有一个单独的事务来完成审计工作并提交。即使父事务回gun，审计记录仍然保留。在Oracle Database 8i以前的版本中，这是实现此功能的一个合适的方法(可能也是唯一的方法)。数据库实际还有一上称为自治事务的特性。自治事务的实现只需一行代码，就完全可以做到他们一直在做的事情。

针对某个问题，开发人员力图提供复杂的大型解决方案，但数据库本身早已解决了这个问题。

除非花些时间来了解已经有些什么，否则你肯定会在某个时候犯同样的错误。

6.轻松解决问题

通常解决问题的途径有两种：容易的方法和困难的方法。

例如，人们经常问“怎么确保最终用户在数据库中只有一个会话”。可能许多应用都有这个需求，不过，如果确实想这样做，人们往往选择困难的方法来实现。例如，他们可能建立一个由操作系统运行的批作业，这个批作业将查看V$SESSION表;如果用户有多个会话，就坚决地关闭这些会话。还有一种办法，他们可能会创建表，用户登录时由应用在这个表中插入一行，用户注销时删除相应行。这种实现无疑会带来许多问题，于是咨询台的铃声大作，因为应用“崩溃”时不会将该行删除。

sys@ORCL>create profile one_session limit sessions_per_user 1;

Profile created.

sys@ORCL>alter user scott profile one_session;

User altered.

sys@ORCL>alter system set resource_limit=true;

System altered.

(当另一会话中scott已conn时)

sys@ORCL>conn scott/tiger

ERROR:

ORA-02391: exceeded simultaneous SESSIONS_PER_USER limit

Warning: You are no longer connected to ORACLE.

(当另一会话中scott已断开时)

sys@ORCL>conn scott/tiger

Connected.

现在有ONE_SESSION配置文件的所有用户都只能登录一次。正所谓磨刀不误砍柴工，花些时间好好熟悉一下所用的工具，了解它能做些什么，在开发时这会节省大量的时间和精力。

实现一个有“无数”层的应用可能看起来很“酷”，但是既然用一个简单的存储过程就能更好、更快地完成任务，而且只利用更少的资源，实现为多层的做法就不是正确的选择。
 

http://www.52ij.com/jishu/5140.htmloracle数据库：开发成功的Oracle应用_笔记11

本文来源 我爱IT技术网 http://www.52ij.com/jishu/5141.html 转载请保留链接。