模式对象依赖关系：减少无效的文档中提到的指南真的有意义吗？

Posted 2021-05-04

doc表示通过视图引用每个表，以便修改或删除视图未引用的列而不使相关对象无效。我找不到一个实际上有意义的案例。

如果依赖对象引用表中的特定列，则修改或删除其他列实际上不会通过view或直接间接更改依赖对象的状态。

答案

如果依赖对象引用表中的特定列，则修改或删除其他列实际上不会更改依赖对象的状态...

没错，但是如果你没有明确提到列呢？

使用上一个问题的设置，这是一个有意义的例子：

create table test (num1 number, num2 number);

create or replace procedure refvirew_intab is
begin
  for r in (select * from test) loop
    dbms_output.put_line(r.num1);
  end loop;
end;
/

此时所有三个对象都有效。如果我删除未使用的num2列：

alter table test drop column num2;

然后程序失效：

OBJECT_NAME          OBJECT_TYPE         STATUS 
-------------------- ------------------- -------
REFVIREW_INTAB       PROCEDURE           INVALID
TEST                 TABLE               VALID  
VEXTEST              VIEW                VALID  

如果重新添加该列，则会针对该视图创建过程：

create or replace view vextest as (select num1 from test);

create or replace procedure refvirew_intab is
begin
  for r in (select * from vextest) loop
    dbms_output.put_line(r.num1);
  end loop;
end;
/

然后修改表现在没有效果：

alter table test drop column num2;

Table TEST altered.

select object_name, object_type, status
from user_objects
where object_name in ('TEST' ,'VEXTEST', 'REFVIREW_INTAB')
order by object_name;

OBJECT_NAME          OBJECT_TYPE         STATUS 
-------------------- ------------------- -------
REFVIREW_INTAB       PROCEDURE           VALID  
TEST                 TABLE               VALID  
VEXTEST              VIEW                VALID  

现在，正如您似乎已经知道的那样，这只适用于select *。如果表格版本有select num1，那么删除第二列对程序没有影响，正如您在问题中所建议的那样。使用select *是不受欢迎的。在这种情况下，只要没有对已删除列的引用，就会自动重新编译该过程并成功。

另一种情况是，如前一个示例中所示，您是在插入表而未指定列名（也是不赞成的）。在这种情况下，更改表定义会使过程无效，可能更具灾难性，因为如果您最终使用不同的数量/顺序/类型的列，它将无法成功重新编译。如果您通过instead of触发器插入视图，那么该过程将无关紧要。 （触发器会，然后可能不会重新编译，具体取决于它正在做什么）。这与文档中的第一个子弹更相关，而不是你要问的第二个子弹;但也适用于删除列。

因此，这是否真的是有用的建议是有争议的。我敢肯定有人使用select *或插入而没有指定列名，有些人使用视图来避免偶然的副作用。我不确定我是否可以看到一个场景，其中一层视图只是为了避免依赖对象失效的可能性值得额外管理，但有些人可能会这样做。

如果你看到对象被无效，甚至是暂时的，你可能做错了 - 通常应该以有计划和受控的方式进行模式更改，以便正确处理副作用，包括对依赖对象的协调更新。但是，其他人会有不同的意见和优先事项。

另一答案

通过视图执行所有操作的文档准则非常荒谬，应该被忽略。

我从未见过有人遵循这些准则。甚至不是Oracle。 Oracle文档通常很棒，但每本手册都包含一些错误和奇怪的意见。

一个好的程序可以最大限度地减少间接级别和对象数量。在一切之上的额外层需要一个很好的理由。避免一些奇怪的情况，这只是由不良的编程实践引起的，不足以证明视图的额外复杂性。