응용 프로그램에는 SQL Server 데이터베이스에있는 수백 가지의 테이블이 있습니다. 이제 사용자가 특정 영역에 대한 쿼리를 작성하고 데이터를 검색 할 수있는 기능을 제공하고자합니다. 현재 데이터베이스 아키텍처가 너무 복잡하기 때문에 간략화 된 인덱싱 된 뷰 집합을 만들어 사용자에게 공개하여 쿼리를 작성하도록 계획하고 있습니다.데이터 다시 쓰기를 위해 인덱싱 된 뷰 사용
테이블의 데이터가 자주 변경됩니다. 그런 테이블에 대해 인덱싱 된 뷰를 사용해도 괜찮습니까? 이 기능을 현재 기능의 오버 헤드로 만들고 싶지 않습니다.
이 절차에 대한 문제점을 예측할 수 있습니까?
감사합니다.
인덱스 된 뷰와 클러스터되지 않은 인덱싱 된 뷰를 사용하여 데이터베이스를 테스트했습니다. 클러스터 된 인덱스가있는 뷰는 아래 테이블에서 업데이트/삭제 작업을 느리게 만듭니다. 하지만 밀리 초 단위로 발생합니다. 나는 이것이 복잡성에 달려 있음을 이해하지만 이것은 내가 나의 시나리오에서 관찰 한 것입니다.
15000 개의 레코드를 업데이트하는 업데이트 쿼리를 실행했습니다. 인덱싱 된 뷰와 - 550ms의 -650ms 클러스터 된 인덱스없이
- 250 개 밀리 - 분당 절약의 280ms
우리의 데이터베이스가없는 100 단위. 따라서 인덱싱 된 뷰가 우리의 경우에 적합하다고 생각합니다.
감사합니다.
인덱스 된 뷰는 테이블이 삽입/업데이트 될 때 성능 오버 헤드를 추가합니다 (삽입/업데이트 된 데이터는 인덱싱 된 뷰에도 유지되어야합니다). 요구 사항에 대한 설명을 토대로 일반보기부터 시작하여이 사용자 작성 쿼리의 성능이 해당보기를 보증하는 경우에만보기 인덱싱을 고려하십시오.
http://technet.microsoft.com/en-us/library/cc917715.aspx#XSLTsection124121120120 – CharithJ
@CharithJ - 좋은 읽을 거리지만 실제로는 그렇지 않습니다. 내가 말한 것을 바꾸지 마라. 삽입/업데이트에 대한 성능 오버 헤드가 여전히 있습니다. 이것은 현재 기능에 영향을 미칠 것입니다. 데이터웨어 하우스에서는 단순히보고 할 데이터를 추출하여 보고서에 더 적합한 비정규 화 테이블 세트에로드합니다. – jlnorsworthy
네, 맞습니다. – CharithJ
아무 것도 무료입니다. 인덱싱 된 뷰를 추가하면 오버 헤드가 추가되어 테스트에 지나치게 많이 걸리는지 여부가 결정됩니다. – Andrew
실제로 데이터웨어 하우스의 시작과 같음 ... – jlnorsworthy