PK 컬럼도 순서가 있다 ?
먼저 PK(PRIMARY KEY ) 에 대해서 알아볼려면 PK 가 무엇인지 알아야 합니다.
즉 데이터 무결성을 만들기 위한 키 입니다. 데이터 무결성에 대해 알아보면 ...
위에 설명에서 3가지 예가 나옵니다.
먼저 첫번째 "한 사원의 사원 ID 값으로 123을 입력한 경우 데이터베이스의 다른 사원이 동일한 값의 ID를 갖지 못하도록 해야 합니다"
->UNIQUE
두번째 "employee_rating 열에 필요한 값이 1에서 5 사이이면 데이터베이스에서 이 범위를 벗어난 값을 허용하지 않아야 합니다"
->CHECK
세번째 "테이블에 사원의 부서 번호를 저장하는 dept_id 열이 있으면 데이터베이스에서 회사의 부서 번호에 유효한 값만 허용해야 합니다"
->FOREIGN KEY
예를 통해 보면 무결성은 많은것들을 내포합니다. 근본적으로 온전한, 안전한 데이터를 유지하는데 있습니다. 그 유지를 위해
FOREIGN KEY 또는 UNIQUE 등 것등을 설정합니다.
(무결성은 3가지로 엔티티, 도메인, 참조 무결성으로 나눠져 있습니다 그부분은 생략합니다)
다시 돌아가 PK 설정은 데이터 무결성을 위해서 입니다. 그렇기 때문에 한개의 값이 될수도 있고 여래개의 값이 합쳐서 고유한 값을 만들어 낼수도 있습니다.
이때 여러개의 값을 합칠때 그 순서는 중요할까요?
PK 컬럼 순서구성에 대한 결론
지금까지 강조해 온 PK 컬럼 순서를 통한 성능저하 예방의 핵심은 프로젝트 설계단계의 마지막인 데이터모델링 수행 시 다수의 컬럼을 사용하는 PK 컬럼 순서에 대해 트랜잭션의 패턴을 분석하고, 이를 검토해 조정해야 한다는 것이다.
PK 순서가 잘못돼 SQL 문장의 성능이 저하되는 경우는 크게 두 가지다. 첫 번째는 단순한 오류 사례와 같이 인덱스를 이용하지 못하고 FULL TABLE SCAN 하면서 성능이 저하되는 경우이다. 두 번째는 복잡한 오류 사례와 같이 인덱스는 이용하는데 그 범위가 넓어져 성능이 저하되는 경우다.
보통 첫 번째는 SQL의 실행계획을 보고 쉽게 튜닝을 하는데, 두 번째의 경우는 UNIQUE 인덱스를 이용해야 하지만 성능이 저하되는 이유로 인해 쉽게 튜닝을 못 하는 경우가 빈번하다. 따라서 인덱스의 정렬(SORT) 구조를 이해한 상태에서 트랜잭션의 특성에 따른 PK 구성을 해 인덱스 범위를 최소화 하는 방향을 데이터 모델에 반영해야 한다.
데이터 모델의 PK 순서가 아무 의미 없는 것 같지만 실전 프로젝트에서 의미 없는 PK 순서를 설계해 성능이 저하되는 경우가 아주 빈번하다. 성능저하 현상의 대부분이 PK가 여러 개의 속성으로 구성된 복합 식별자일 때 PK 순서를 고려하지 않고 데이터모델링을 한 경우에서 온다. 이건 단순하지만 자주 범하는 오류다.
결론 부터 정리하면 where 에 넣어주는 값에 순서와 PK 순서가 일치해야 full scan 을 하지 않는다는 말 입니다.
즉 PK 순서를 자주 where 에 맞춰 구성 하거나, where 을 작성할때 PK 순서를 맞춰 넣어줘야 합니다.
아주 간단한 실수가 성능 저하를 만들수 있기 때문입니다.
먼저 PK(PRIMARY KEY ) 에 대해서 알아볼려면 PK 가 무엇인지 알아야 합니다.
테이블에는 일반적으로 테이블의 각 행을 고유하게 식별하는 값을 가진 열 또는 열 조합이 포함되어 있습니다.
이러한 열이나 열 조합은 테이블의 PK(기본 키)라고 하며 테이블에 엔터티 무결성을 적용합니다.
즉 데이터 무결성을 만들기 위한 키 입니다. 데이터 무결성에 대해 알아보면 ...
데이터 무결성을 강제 적용하면 데이터베이스에 있는 데이터의 품질이 보장됩니다.1)예를 들어 한 사원의 사원 ID 값으로 123을 입력한 경우 데이터베이스의 다른 사원이 동일한 값의 ID를 갖지 못하도록 해야 합니다. 2)employee_rating 열에 필요한 값이 1에서 5 사이이면 데이터베이스에서 이 범위를 벗어난 값을 허용하지 않아야 합니다. 3)테이블에 사원의 부서 번호를 저장하는 dept_id 열이 있으면 데이터베이스에서 회사의 부서 번호에 유효한 값만 허용해야 합니다.
출처 : technet.microsoft.com
(http://msdn.microsoft.com/ko-kr/library/ms184276.aspx)
(http://msdn.microsoft.com/ko-kr/library/ms184276.aspx)
위에 설명에서 3가지 예가 나옵니다.
먼저 첫번째 "한 사원의 사원 ID 값으로 123을 입력한 경우 데이터베이스의 다른 사원이 동일한 값의 ID를 갖지 못하도록 해야 합니다"
->UNIQUE
두번째 "employee_rating 열에 필요한 값이 1에서 5 사이이면 데이터베이스에서 이 범위를 벗어난 값을 허용하지 않아야 합니다"
->CHECK
세번째 "테이블에 사원의 부서 번호를 저장하는 dept_id 열이 있으면 데이터베이스에서 회사의 부서 번호에 유효한 값만 허용해야 합니다"
->FOREIGN KEY
예를 통해 보면 무결성은 많은것들을 내포합니다. 근본적으로 온전한, 안전한 데이터를 유지하는데 있습니다. 그 유지를 위해
FOREIGN KEY 또는 UNIQUE 등 것등을 설정합니다.
(무결성은 3가지로 엔티티, 도메인, 참조 무결성으로 나눠져 있습니다 그부분은 생략합니다)
다시 돌아가 PK 설정은 데이터 무결성을 위해서 입니다. 그렇기 때문에 한개의 값이 될수도 있고 여래개의 값이 합쳐서 고유한 값을 만들어 낼수도 있습니다.
이때 여러개의 값을 합칠때 그 순서는 중요할까요?
PK 컬럼 순서구성에 대한 결론
지금까지 강조해 온 PK 컬럼 순서를 통한 성능저하 예방의 핵심은 프로젝트 설계단계의 마지막인 데이터모델링 수행 시 다수의 컬럼을 사용하는 PK 컬럼 순서에 대해 트랜잭션의 패턴을 분석하고, 이를 검토해 조정해야 한다는 것이다.
PK 순서가 잘못돼 SQL 문장의 성능이 저하되는 경우는 크게 두 가지다. 첫 번째는 단순한 오류 사례와 같이 인덱스를 이용하지 못하고 FULL TABLE SCAN 하면서 성능이 저하되는 경우이다. 두 번째는 복잡한 오류 사례와 같이 인덱스는 이용하는데 그 범위가 넓어져 성능이 저하되는 경우다.
보통 첫 번째는 SQL의 실행계획을 보고 쉽게 튜닝을 하는데, 두 번째의 경우는 UNIQUE 인덱스를 이용해야 하지만 성능이 저하되는 이유로 인해 쉽게 튜닝을 못 하는 경우가 빈번하다. 따라서 인덱스의 정렬(SORT) 구조를 이해한 상태에서 트랜잭션의 특성에 따른 PK 구성을 해 인덱스 범위를 최소화 하는 방향을 데이터 모델에 반영해야 한다.
데이터 모델의 PK 순서가 아무 의미 없는 것 같지만 실전 프로젝트에서 의미 없는 PK 순서를 설계해 성능이 저하되는 경우가 아주 빈번하다. 성능저하 현상의 대부분이 PK가 여러 개의 속성으로 구성된 복합 식별자일 때 PK 순서를 고려하지 않고 데이터모델링을 한 경우에서 온다. 이건 단순하지만 자주 범하는 오류다.
출처 : 아는 만큼 보이는 데이터베이스 설계와 구축 1장
(http://www.imaso.co.kr/?doc=bbs/gnuboard.php&bo_table=article&wr_id=36957
)
(http://www.imaso.co.kr/?doc=bbs/gnuboard.php&bo_table=article&wr_id=36957
)
결론 부터 정리하면 where 에 넣어주는 값에 순서와 PK 순서가 일치해야 full scan 을 하지 않는다는 말 입니다.
즉 PK 순서를 자주 where 에 맞춰 구성 하거나, where 을 작성할때 PK 순서를 맞춰 넣어줘야 합니다.
아주 간단한 실수가 성능 저하를 만들수 있기 때문입니다.
공유하기 버튼
|
|
