필자는 시간을 별도의 열로 분리하면 실제 성능이 향상된다는 것을 알았습니다. 예컨대 년, 월, 일 등 ...Datawarehouse의 성능 차이가 비정규 화 된 시간
이 데이터베이스는 이미 시간을 분할 있도록 시간 열을 통해 모든 인덱스를 처리하고 사용되지 않습니다 variantes 인덱스 수백만을 추가하기위한 몇 가지 스마트 approch이 있습니까?
성능 차이가 있습니까?
가능한 쿼리는 월요일 오후 13 시부 터 14 시까 지 판매가 될 수 있습니다.
this SO question/answer을 살펴보십시오.
윤곽을 그리는 특정 시나리오 (매주 월요일 13 : 00-14 : 00)는 datetime 데이터에 대한 일반 인덱스로 올바르게 처리 할 수 없습니다.
요일과 시간 부분으로 datetime 데이터를 많이 분석해야합니다. 이 시나리오에서는 일주일 동안 열과 시간 (시간)으로 열을 분리하면 훨씬 더 잘 작동하고 개별적으로 또는 복합 (둘 다에 걸쳐)으로 인덱싱 할 수 있습니다.
성능이 매우 다릅니다 - 주당 + 시간대에 색인을 사용하여 데이터의 1/180 (이론적 평균) 또는보다 현실적으로 데이터의 약 1/50 (근무 시간)을 보는 대신, 그렇지 않으면 쿼리에서 2 개의 변환을 실행하여 (요일 + 시간 구성 요소를 얻은 다음) 필터를 통해 쿼리를 실행해야합니다.
많은 스타 스키마에서 시간 차원을 갖는 것이 유용합니다. 이 차원 테이블에서 명시 적으로 배치 된 요일, 월 등을 갖는 것이 유용 할 수 있습니다. 이러한 속성 중 많은 부분은 SQL Dialect에 내장 된 함수를 통해 액세스 할 수 있습니다. 또한이 데이터를 구체화하는 것보다 기능을 사용하는 경우 디스크 I/O가 적습니다. 그러나 달력 기능이 데이터처럼 보이면 특정 시간 조각에 대한 보고서 작성이 훨씬 쉬워집니다.
이것은 정말로 유용 할 수 있습니다. 기업은 날짜가 일년에 쉽게 매핑되지 않는 "회계 분기"라는 단위에 속할 수있는 독특한 "회사 달력"을 보유하고 있습니다. 시간 차원 테이블을 생성하는 단일 프로그램에 모든 달력 단점을 넣으면웨어 하우스 코드의 나머지 부분을 훨씬 더 깨끗하게 만들 수 있습니다.
모든 차원 테이블과 마찬가지로 세분성을 올바르게 설정하는 것이 매우 중요합니다. 하루에 한 행만 원한다면 3,650 개가 넘는 행과 함께 10 년 동안의 날짜를 저장할 수 있습니다.이 테이블은 오늘날의 표준에 따라 작은 테이블입니다. 경우에 따라 "교대조"(8 시간)가 올바른 세분성으로 밝혀졌습니다. 그것은 데이터의 사용에 달려 있습니다.
웨어 하우스를 설정할 때 데이터가 "변태"를 겪을 수 있도록 준비하고 예기치 않은 요구 사항에 직면했을 때 "시험"을 치를 준비를하십시오.
함수 기반 인덱스가 하나의 가능한 옵션입니다. 인덱싱 된 뷰는 다른 뷰입니다.
새 속성을 만드는 것만으로 성능이 향상되는 것은 아닙니다. 성능 차이는 데이터 저장 및 색인 방식의 근본적인 변경 때문입니다. 따라서 별도의 날짜와 시간 열을 만드는 것이 성능 향상이라고 말하는 것은 오해의 소지가 있으며 지나치게 단순합니다. 그러나 별도의 시간 열을 만드는 것이 다른 이유, 예를 들어 선명도, 쿼리 논리 단순화 또는 DBMS 날짜/시간 유형 및 기타 기능의 장점을 고려하여 좋은 아이디어 일 수 있습니다.