Chinaunix首页 | 论坛 | 博客
  • 博客访问: 18702474
  • 博文数量: 7460
  • 博客积分: 10434
  • 博客等级: 上将
  • 技术积分: 78178
  • 用 户 组: 普通用户
  • 注册时间: 2008-03-02 22:54
文章分类

全部博文(7460)

文章存档

2011年(1)

2009年(669)

2008年(6790)

分类: Mysql/postgreSQL

2008-04-01 14:39:40

 

视图处理功能概念未优化:

·不能在视图上创建索引。

·对于使用MERGE算法处理的视图,可以使用索引。但是,对于使用临时表算法处理的视图,不能在其基表上利用索引提供的优点(尽管能够在临时表的生成过程中使用索引)。

在视图的FROM子句中不能使用子查询。未来该限制将被放宽。

存在一个一般原则,不能更改某一表并在子查询的相同表内进行选择。请参见I.3节,“对子查询的限制”。

如果从表选择了视图并接着从视图进行了选择,同样的原理也适用,如果在子查询中从表选择了视图并使用MERGE算法评估了视图,也同样。例如:

CREATE VIEW v1 AS
SELECT * FROM t2 WHERE EXISTS 
(SELECT 1 FROM t1 WHERE t1.a = t2.a);
UPDATE t1, v2 SET t1.a = 1 WHERE t1.b = v2.b;

如果视图是使用临时表评估的,可从视图子查询中的表进行选择,并仍能更改外部查询中的表。在该情况下,视图将被具体化,因此,你实际上不能从子查询的表中进行选择并“同时”更改它(这是你打算强制MySQL使用临时表算法的另一原因,其方法是在视图定义中指定ALGORITHM = TEMPTABLE关键字)。

可以使用DROP TABLE或ALTER TABLE来舍弃或更改视图定义中使用的表(它会是视图失效),而且舍弃或更改操作不会导致告警。但在以后使用视图时会出错。

视图定义是通过特定语句“冻结”的:

·如果PREPARE预处理的语句引用了视图,以后每次执行语句时看到的视图内容与预处理视图时的内容相同。即使在语句预处理完成之后、在执行语句之前更改了视图定义,情况也同样。例如:

·CREATE VIEW v AS SELECT 1;

·PREPARE s FROM 'SELECT * FROM v';

·ALTER VIEW v AS SELECT 2;

·EXECUTE s;

EXECUTE语句返回的结果是1,而不是2。

· 如果存储子程序中的语句引用了视图,语句所见到的视图内容与首次执行语句时的相同。这意味着,如果语句是以循环方式执行的,进一步的语句迭代见到的视图内容是相同的,即使在循环过程中更改了视图定义也同样。例如:

·CREATE VIEW v AS SELECT 1;
·delimiter //
·CREATE PROCEDURE p ()
·BEGIN
·DECLARE i INT DEFAULT 0;
·WHILE i < 5 DO
·SELECT * FROM v;
·SET i = i + 1;
·ALTER VIEW v AS SELECT 2;
·END WHILE;
·END;
·//
·delimiter ;
·CALL p();

如果调用了程序p(),每次通过循环时SELECT返回1,即使在循环内更改了视图定义也同样。

关于视图的可更新性,对于视图,其总体目标是,如果任何视图从理论上讲是可更新的,在实际上也应是可更新的。这包括在其定义中有UNION的视图。目前,并非所有理论上可更新的视图均能被更新。最初的视图实施有意采用该方式,为的是尽快地在MySQL中获得有用的可更新视图。很多理论上可更新的视图现已能更新,但限制依然存在:

·其子查询位于WHERE子句之外任何位置的可更新视图。对于某些其子查询位于SELECT列表中的视图,也是可更新的。

·不能使用UPDATE来更新定义为Join的视图的1个以上的基表。

·不能使用DELETE来更新定义为Join的视图。

(责任编辑:卢兆林)

阅读(478) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~