이와 동일한 로직이 필터링된 로우에도 적용된다. 예를 들어 비활성화된 고객은 vCustomerStatistics에는 포함되지만 vActiveCustomers에서는 제외되므로 결국 최종 뷰인 vActiveCustomerStatistics에서도 이들 내역은 볼 수 없다. 따라서 예상보다 많은 I/O 작업이 수반될 수 있다. 관련된 내용은 ‘BETTER WAY 46. 실행 계획의 작동 원리를 이해하자’에서 자세히 설명한다. 여기서 사용한 예는 지나치게 단순화한 측면이 없지 않지만, 다른 뷰를 참조할 때 옵티마이저가 단순히 인라인화할 수 없는 뷰를 만드는 것은 꽤 쉽다. 게다가 인라인화할 수 없는 이런 뷰를 생성하는 방법도 여러 가지다. 결국 일반적으로 실제 필요한 데이터만 정확히 요구하는 좀 더 간단한 쿼리 표현식으로 뷰를 만들 때 옵티마이저는 더 나은 작업을 수행한다.

이런 이유로 뷰를 참조하는 뷰는 만들지 않는 것이 상책이다. 이미 만든 뷰를 다른 형태로 봐야 한다면 적절한 필터나 그룹으로 묶어 기준 테이블을 직접 참조하는 새 뷰를 만들면 좋다. 또 뷰에서도 서브쿼리를 사용할 수 있는데, 뷰에서만 볼 수 있는 계산 값을 집계할 때 매우 유용하다. 이것은 사용하기 편리하지 않은 뷰 생성을 남발하지 않고 쉽게 데이터베이스를 관리하는 데 도움이 되는 접근 방법이다. ‘BETTER WAY 42. 가능하면 서브쿼리 대신 공통 테이블 표현식을 사용하자’에서 더 많은 기법을 볼 수 있다.