안녕하세요.
이번에 직접 SQL 서버 테이블 구성을 잡아보고 있는 중에 궁금한 점이 있어 질문드립니다.
클러스터 Index를 최대한 활용을 하고 싶은데
현재 테이블 내용은 일반 게시판 메인 테이블과 같은 형태입니다.
그런데 primary key를 선정할 때 날짜로 가야할지 아니면 증가하는 seq로 가야하나 아니면 겹치지않는 특정 값으로 가야할까요
1. 20150129101213000001 (yyyymmddHHMMSS + 증가되는 특정값<일별로 초기화>)
2. 증가되는 seq 1,2,3,4,5
3. 유니크한 값인 201511121314_userID<예>
데이터는 주로 insert만 되며 연속해서 게시판 글이 들어가듯 들어가게 됩니다.
하지만 2번 방법으로 했을 때 join이나 하나의 데이터를 조회할때는 좋겠지만 날짜 조회시 불필요 하다 판단됩니다.
테스트를 했을 때는 아래와 같았습니다.
1. 증가되는 seq 값으로 했을 때 index가 없는 datetime인 날짜로 조회 했을 경우 클러스터 인덱스를 태웁니다.
이 방법이 현 상태에서 가장 좋은 방법인지 확고하지 않아 질문을 남깁니다.
질문이 PK선정에 관한거라 PK 위주로 답을 해보면
PK의 선정은 어쩌면 성능하고는 관련이 없습니다. (어쩌면 있지도 모름 ㅋㅋㅋ)
PK의 선정은 오로지 데이터를 구분짓는 식별자로 정해져야죠.
예를 들어서 회원테이블이라면 회원번호 또는 회원아이디가 PK가 되어야 겠죠.
하지만 저는 실제 식별자를 PK로 선정했을 경우 프로그래밍 하기가 좀 귀찮은 문제가 있더군요.
예를 들어서 회원아이디를 PK로 선정한 후 회원테이블의 자식 테이블에 포린키를 걸어놨을 경우
부모테이블의 PK를 변경할 수 없는 경우가 생깁니다.
말하자면 회원아이디를 수정하지 못한다는거죠. (물론 회원아이디 같은 경우는 잘 수정 안합니다만...)
그래서 저는 PK후보를 유니크 인덱스로 만들어서 PK를 대체하도록 만들고
아이덴티티를 컬럼을 PK로 만들기도 합니다. 질문자분도 이런 방법을 쓰시나보네요.
그렇게 되면 조인하기도 쉽고, 부모테이블의 키가 바뀌어야 하는 경우에도 유연합니다.
여기까지는 오로지 데이터 관점에서 본것이고
여기에 성능문제를 고려한다면 어떤 인덱스가 클러스터드가 되어야 할지를 고민해야 합니다.
꼭 PK가 클러스터드 일 필요는 없습니다.
엑세스 패턴과 쿼리의 빈도에 따라 선정되어야 겠죠.