스키마 개체 종속성 : 무효화를 줄이기 위해 doc에 언급 된 지침이 실제로 의미가 있습니까?

doc은 뷰를 통해 각 테이블을 참조하므로 뷰가 참조하지 않는 열을 종속 개체를 무효화하지 않고 수정 또는 삭제할 수 있습니다. 나는 이것이 실제로 합리적 일 수있는 한 가지 사례를 발견하지 못한다.스키마 개체 종속성 : 무효화를 줄이기 위해 doc에 언급 된 지침이 실제로 의미가 있습니까?

종속 개체가 테이블의 특정 열을 참조하는 경우 다른 열을 수정하거나 삭제하면 실제로 종속 개체의 상태가 간접적으로 view 또는 직접 변경되지 않습니다.

출처

2017-12-29 sql_dummy

종속 객체가 수정 테이블에서 특정 열을 참조하거나 의존하는 객체의 상태를 변경하지 않습니다 정말 다른 열을 삭제하는 경우 ...

사실,하지만 당신이 아닌 경우 명시 적으로 열을 참조 하시겠습니까? 세 개의 객체가 유효이 시점에서

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; 
/

: 이전 질문에서 셋업을 사용하여

는

, 여기가 이해 수있는 예입니다. 열에 부가 다시 경우

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

상기 절차 대신 볼에 대해 생성된다 : 다음 절차 무효화

alter table test drop column num2;

: I는 미사용 num2 열 놓으면

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 *을 사용하면 눈살을 찌푸리게됩니다. 이 경우 프로 시저는 자동으로 다시 컴파일되고 삭제 된 열에 대한 참조가 실제로없는 한 성공적으로 다시 컴파일됩니다.

또 다른 시나리오는 앞의 예와 같이 열 이름을 지정하지 않고 표에 삽입하는 것입니다 (즉, frowned). 이 경우 테이블 정의를 변경하면 다른 숫자/순서/유형의 열로 끝나면 성공적으로 다시 컴파일되지 않으므로 다소 심각한 문제가 발생할 수 있습니다. instead of 트리거를 통해 뷰에 삽입하는 경우 프로 시저는 상관 없습니다. (트리거는 다음과 같습니다. 은 수행중인 작업에 따라이 다시 컴파일되지 않을 수 있습니다). 그것은 문서에서 첫 번째 글 머리 기호와 관련이 있지만 두 번째 질문은 아닙니다. 열을 떨어 뜨리는데도 적용됩니다.

정말 유용한 조언인지 여부는 논쟁의 여지가 있습니다. select *을 사용하거나 열 이름을 지정하지 않고 삽입하는 사람들이 있으며 그 중 일부는보기를 사용하여 이러한 가끔 부작용을 피할 수 있습니다. 나는 종속 객체 무효화의 가능성을 피하기위한 뷰 레이어가 추가 관리의 가치가있는 시나리오를 볼 수 있는지 확신하지 못합니다. 그러나 일부 사람들은 아마 그렇게 할 것입니다.

일시적 으로라도 개체가 무효화되는 것을 볼 수 있습니다. 일반적으로 스키마 변경은 종속 개체에 대한 통합 된 업데이트를 포함하여 부작용이 올바르게 처리되도록 계획되고 제어 된 방식으로 수행되어야합니다. 그러나 또 다른 사람들은 다른 견해와 우선 순위를 가질 것입니다.

출처

2017-12-29 19:09:34

보기를 통해 모든 것을 수행하기위한 문서화 가이드 라인은 우스꽝스럽고 무시해야합니다.

본 가이드 라인을 본 사람은 본 적이 없습니다. 오라클조차도 아닙니다. 오라클 설명서는 대개 훌륭하지만 모든 설명서에는 몇 가지 실수와 이상한 의견이 있습니다.

좋은 프로그램은 간접 레벨과 개체 수를 최소화합니다. 상단의 추가 레이어가 모두이면 좋은 이유가 있습니다. 어쨌든 나쁜 프로그래밍 관행에 의해서만 발생하는 몇 가지 이상한 경우를 피하는 것은 뷰의 복잡성을 정당화하기에 충분하지 않습니다.

출처

2017-12-30 05:06:05

스키마 개체 종속성 : 무효화를 줄이기 위해 doc에 언급 된 지침이 실제로 의미가 있습니까?

답변

관련 문제