Oracle数据库视图管理经验技巧

　　视图，对于数据库来说，是一个最基本的、也是最重要的功能之一。数据库视图设计的好坏，直接跟数据库的性能相关。而且，在大型数据库设计中，大家分 工合作，基础表的设计与报表视图的设计往往由不同的人负责。所以，视图的设计管理跟基础表的设计管理一样，都有很大的学问。在这篇文章中，笔者将结合自己 在视图设计管理方面的工作经验，谈谈在这方面的一些鲜为人知的技巧。

 

　　技巧一：把基础表与视图脱离开来。

 

　　一般来说，视图都是在基础表的上面建立起来的。也就是说，要先有基础表，而后有视图。但是，在大型数据库的设计过程中，出于项目时间的考虑，往往基 础表与视图的设计是同时进行的。如一些人负责基础表的建立，另一些人则负责视图的设计与建立等等。在这个过程中，往往基础表不存在的时候，就需要建立一些 视图，以加快项目的进度。

为了使得基础表的创建和修改与视图的创建于修改没有必然的联系，以便于员工之间工作的同步，提高工作效率，所以，在Oracle数据库中提出了一个 “强制创建视图”的概念。也就是说，正常情况下，如果基本表不存在，则创建视图就会失败。但是，我们可以在创建视图的过程中，加入一个参数，只要创建视图 的语法没有错误的话，即使基础表不存在，仍然可以建立这张表格。这个有用的参数就是force选项。如我们建立视图时，CREATE FORCE VIEW TEXT，只需要在关键字VIEW之前加入FORCE参数即可。如此的话，系统在编译视图的时候，就不会去考虑基础表是否存在。

不过这里要注意一点，若基础表不存在的话，则编译后该视图的状态为“无效”，不能再这个视图的基础上执行一些操作，如查询操作等等。当下次访问这个 视图的时候，则数据库会对这个视图进行重新编译，若此时基础表存在了，则该基础表就会变为有效;若基础表不存在，则这视图就会失效。

　　Oracle数据库之所以如此设置，主要是出于在数据库设计过程中协同办公的需要。有了这个功能之后，则在数据库建立的过程中，只要把数据库基础表 与视图设计好之后，大家就可以分工合作，在数据库中建立相关的对象。不然的话，要等基础表建立好之后再建立视图，如此就会明显的影响数据库建立的进度。所 以，在数据库建立的过程中，特别是中大型的数据库系统，这是一个很实用的功能。

 

　　技巧二：创建视图的理想步骤。

 

　　无论是简单视图，还是比较复杂的视图，笔者觉得数据库管理员在创建视图的时候，最好能够遵循一定的步骤。这一方面是因为视图的更改相对来说，是一件 比较麻烦的工作，所以，我们在建立视图的时候，要确保视图的准确性。另一方面，视图是基础表的一个体现形式，若不按步骤来做的话，有可能就不能够达到我们 预计的需求。

当然这个步骤没有官方的版本，完全是数据库管理员根据实际的经验总结出来的。这个步骤不仅对Oracle数据库有效，对于其他数据库来说，也是类似的道理。

 

　　一般来说，视图创建可以分为五步走，

 

　　第一步：先考虑Select语句的编写。我们知道，视图其实就是一个Select语句的集合。所以，我们建立视图的第一步，就是考虑这个 Select语句该如何编写。这个Select语句编写的是否合理、执行效率的高低直接影响着这个视图的性能。另外，在Select语句中，可能还会有格 式的控制、内容的编排等等。如在Select语句中，可以把一些字段合并成一个字段;也可以把相关的内容进行倒置等等。这些功能都是Select语句完成 的。所以可以这么说，Select语句的编写是视图建立的基础。

 

　　第二步：对这个Select语句进行测试。当我们编写好Select语句之后，就需要在数据库中执行这条语句，看其能否查询到我们想要的值。在对 Select语句进行测试的时候，需要注意一个问题，有时候Select查询语句可以查到准确的数据，但是在以这条语句建立视图的时候，可能就会通不过。 如在一些表之间的连接查询的时候，如果两个表中有个字段名相同，是可以的。因为他们除了字段名字之外，还有表名一起来定义这个字段。如A.name与 B.name。这是不算重名的。但是，若在建立视图的时候，这就会被认为是重复的列明，需要对其中的一个列名进行重定义。这一点在数据库视图建立的时候， 要特别的注意。

 

　　第三步：考虑查询结果的准确性。通过查询语句把我们想要的结果查询出来后，我们就需要看看这个结果是否满足我们的需要。在这个过程中，我们主要注意 两点。一是形式字段是否齐全。在一些应用系统中，若数据库的视图要能够被前台的应用程序调用的话，则必须包含一些形式字段。如笔者以前在设计一个 ERP系统的时候，若前台系统要调用数据库中的视图的时候，必须包含记录更新时间、更新者、记录创建时间、创建者等相关信息。若缺乏这些信息的话，则前台 调用这张视图的时候，就会出现错误。故在考虑查询结果准确性的问题的时候，就要考虑到前台应用程序的需要，看看这些形式字段是否齐全。二是实体内容的完整 性。我们到底需要显示表中的哪些字段呢，这个我们在这里要确认清楚。若显示内容太多的话，则会影响视图的执行效率，而且也会降低视图的安全性作用;但是， 若字段内容显示不足的话，则以后要添加字段的话，会比较麻烦，有一定的工作量。所以在这个检验的时候，需要根据视图的实际功用，确定视图需要显示的内容。

 

　　第四步：视图的修饰。有时候，为了阅读的方便，我们需要对查询结果进行一些修饰。如现在有两张表，一张是员工基本信息表，这表中有员工姓名、员工职 位编号等等;另一张表是职位基本信息表，在这表中有职位编号、职位名称。我们希望在视图中能够如下显示：“职位：员工名字”，如数据库工程 师：Victor。也就是说，把两个字段合并起来，并且在中间加入一个冒号。这些格式性的内容都是在查询的时候实现的。所以，我们确认查询的结果没有错误 之后，接下来就要确认格式问题。若能够在视图中规范这些格式问题，则前台的程序设计就会相对来说比较简单。

 

　　第五步：建立视图。等到上面四步都确认无误后，我们就要根据上面的查询语句来建立视图了。不过在这一步过程中，也有一些问题需要注意。一是视图名字 的命名规格。我们除了遵循数据库的强制命名格式之外，如不能以数字开头等等，还需要遵循一些软规则。如视图最好能够以V开头，跟基础表进行隔开;另外在视 图命名中，能够根据应用模块的不同，来进行分类，并体现在视图的名字中。这对于我们后续视图的查找都具有非常现实的意义。二是虽然可以在视图中直接更新基 础表，不过，为了安全与数据统一的考虑，我们这些过来人一般都不建议通过视图来直接更新基础表中的数据。虽然数据库提供了类似的功能。若要更改相关数据的 话，则直接去更改基础表的内容为好。在建立视图的时候，默认情况下是不能够通过视图直接更新基础表。