답변:
구체화 된 뷰를 사용하면 얻을 수있는 가장 큰 이점 중 하나는 Oracle이 데이터를 동기화 상태로 유지한다는 것입니다. 별도의 집계 테이블이있는 경우 데이터를 동기화 된 상태로 유지해야합니다. 일반적으로 합리적인 양의 코드와 적절한 수준의 테스트가 필요하며 대부분의 조직은 집계 테이블이 동기화되지 않도록하는 실수를 범하는 실수를 저지 릅니다. 집계 테이블의 증분 새로 고침을 구현하려고 할 때 특히 그렇습니다.
또 다른 주요 이점은 설정에 따라 사용자가 기본 테이블에 대해 쿼리를 발행 할 때 쿼리 재 작성을 사용하여 구체화 된 뷰를 사용할 수 있다는 것입니다. 예를 들어 일별, 월별 및 연간 집계 결과를 생성하는 세부 사항 테이블에 대한 기존 보고서가 많은 경우 기본 테이블에서 매일 레벨로 데이터를 집계하는 구체화 된보기를 작성할 수 있습니다. 기존의 모든 쿼리에 대해 구체화 된 뷰를 활용하십시오. 따라서 새로운 집계 테이블을 사용하거나 DBMS_ADVANCED_REWRITE쿼리를 직접 다시 작성 하기 위해 수십 개의 보고서를 작성하고 다시 작성하지 않고도 데이터웨어 하우스에서보고 워크로드를 훨씬 쉽게 최적화 할 수 있습니다 .
MV를 사용하는 좋은 사례 중 하나는 때때로 데이터를 집계하고이 요약 정보를 큰 테이블에서 자주 그리고 빠르게 얻고 자하는 것입니다. 구체화 된 뷰가 없으면 일부 테이블을 비정규 화하고 코드를 통해 집계를 유지하거나 많은 행 집합을 반복적으로 스캔해야합니다. 어느 쪽이든 대시 보드 및 유사한 온라인 응용 프로그램에서 항상 허용되는 것은 아닙니다. 결과를 별도의 테이블에 보관하면 애플리케이션 코드가 복잡해지며 @Justin Cave가 말했듯이 수동으로 집계 된 데이터가 동기화되어 있는지 확인해야합니다. 원래 테이블의 데이터와 함께.
오라클 직원은 아니지만 다른 사용 사례는 타사 솔루션입니다. 이들은 일반적으로 설계 변경을 지원하지 않지만 MV는 코드에 "보이지"않지만 사용자 지정보고 / 데이터 추출에는 액세스 할 수 있습니다.
스토리지 비용이 발생하고 삽입 / 업데이트 시간에 영향을 줄 수 있다는 점에서 자유롭지는 않지만, 구체화 된 데이터를 "직선보기"대 검색하거나 실제 테이블을 작성하고 주변 ETL을 유지 보수하는 데 소요 된 시간으로 상쇄 될 수 있습니다.
마지막으로, 그렇게하면 공급 업체와의 상담 계약이 무효화 될 수 있습니다. 변호사 -blah-blah-blah
대신에 직접가는 구체화 된 뷰 설명해 보자 보기 .
기본적으로 뷰는 테이블과 달리 논리적으로 존재합니다. 사용자에게 특정 열을 숨기려면 테이블을 사용할 수 없습니다. 보안을 달성 할 수있는 뷰를 만듭니다.
유스 케이스 : 보기가 그룹별로 10 개의 테이블과 관련되어 있고 함수에 수백만 개의 행이있는 경우 실행하는 데 시간이 오래 걸립니다.
구체화 된 뷰를 통해 데이터를 더 빠르게 얻을 수 있습니다. 구체화 된 뷰는 실제로 데이터베이스에 존재합니다. 기본 테이블이 업데이트 될 때마다 구체화 된보기가 업데이트됩니다.
구체화 된 뷰는 쿼리 정의에 따라 주기적으로 업데이트되며 테이블에서는이를 수행 할 수 없습니다.
구체화 된 뷰는 쿼리 결과가 포함 된 데이터베이스 개체입니다. 원격으로 위치한 데이터의 로컬 사본이거나 테이블 데이터의 집계를 기반으로 요약 테이블을 작성하는 데 사용됩니다. http://www.oraappdata.com/2016/04/materialized-view.html
ON DEMAND기본 새로 고침 동작입니다. 로 구체화 된보기는로 작성해야합니다ON COMMIT. 구체화 된 관점을 유지하는 것은 자유롭지 않습니다. 그래도 트리거보다 저렴합니다.