인조키?
인조키가 뭔지 몰라서 찾아보려 했는데 밑에 게이가 말해줬네 고맙다 이기
대체키 만들어서 pk로 쓰는거임. mysql은 테이블 구조가 pk에 강제로 엮이는 클러스티드테이블이라 대체키가 반강제고 나머지db들은 힙테이블이라서 선택이긴한데 pk를 바꾸는 경우나 복합키인 경우에는 pk로잡기 불안정해서 대체키(인조키)를 만들어서 그걸 pk로 삼는거
고렇구만 고맙다 이기
원본 테이블의 정보를 PK로 쓰면 외부에 정보가 노출됨 그걸 막기 위함임 - dc App
그런 의미도 있구만 고맙다 이기
시리얼한 번호(인조키)를 pk로 걸어두면 이점이 1.인덱스 컬럼이 하나니까 인덱스의 높이가 낮을확률이 높아져서 성능 향상이 되겠지? 2. 해당 테이블의 키를 외래키로 가져야 한다고 쳤을때 컬럼 하나만 추가하면 되니 테이블도 압축되고 join시 연산할 컬럼이 하나밖에 없으니 join 속도도 복합키 보다빠르겠지 - dc App
보통 팩트테이블에 au.to increment열을 pk로 많이써 - dc App
아니다 pk로 많이쓴다는 취소고 팩트테이블에 au.to increment열이 많고 이를 외래키로 자식테이블에 가지고 있는 모델이 흔하지 - dc App
2.는 정규화하고도 연관이있음 - dc App
@30세전에특급DBA 아무대서도 안써도 조인 속도가 빨라지는거노 이기?
아니 같은테이블에서 같은 데이터를 대상으로 조인한다 쳤을때 au.to increment 단일키 인덱스랑 복합키 인덱스랑 아주 미세하겠다만 조인속도가 단일키 인덱스가 더 빠르지 않을까? - dc App
@30세전에특급DBA 호옹이? 인덱스 갯수에 의해서도 조인속도가 달라질수 있다는거구만 고맙다 이기
아 다르고 어 다른건데 인덱스 갯수에 따라서 성능 영향이 있는건 데이터의 수정이 발생했을때 (c,u,d) 반영이 필요한 인덱스별로 반영 작업으로 인해 영향이 있고 내가말한건 인덱스 키 컬럼 갯수임 - dc App
@30세전에특급DBA 아 그렇구만 내가 대충얘기했구만 정정 고맙다 이기
인조키?
인조키가 뭔지 몰라서 찾아보려 했는데 밑에 게이가 말해줬네 고맙다 이기
대체키 만들어서 pk로 쓰는거임. mysql은 테이블 구조가 pk에 강제로 엮이는 클러스티드테이블이라 대체키가 반강제고 나머지db들은 힙테이블이라서 선택이긴한데 pk를 바꾸는 경우나 복합키인 경우에는 pk로잡기 불안정해서 대체키(인조키)를 만들어서 그걸 pk로 삼는거
고렇구만 고맙다 이기
원본 테이블의 정보를 PK로 쓰면 외부에 정보가 노출됨 그걸 막기 위함임 - dc App
그런 의미도 있구만 고맙다 이기
시리얼한 번호(인조키)를 pk로 걸어두면 이점이 1.인덱스 컬럼이 하나니까 인덱스의 높이가 낮을확률이 높아져서 성능 향상이 되겠지? 2. 해당 테이블의 키를 외래키로 가져야 한다고 쳤을때 컬럼 하나만 추가하면 되니 테이블도 압축되고 join시 연산할 컬럼이 하나밖에 없으니 join 속도도 복합키 보다빠르겠지 - dc App
보통 팩트테이블에 au.to increment열을 pk로 많이써 - dc App
아니다 pk로 많이쓴다는 취소고 팩트테이블에 au.to increment열이 많고 이를 외래키로 자식테이블에 가지고 있는 모델이 흔하지 - dc App
2.는 정규화하고도 연관이있음 - dc App
@30세전에특급DBA 아무대서도 안써도 조인 속도가 빨라지는거노 이기?
아니 같은테이블에서 같은 데이터를 대상으로 조인한다 쳤을때 au.to increment 단일키 인덱스랑 복합키 인덱스랑 아주 미세하겠다만 조인속도가 단일키 인덱스가 더 빠르지 않을까? - dc App
@30세전에특급DBA 호옹이? 인덱스 갯수에 의해서도 조인속도가 달라질수 있다는거구만 고맙다 이기
아 다르고 어 다른건데 인덱스 갯수에 따라서 성능 영향이 있는건 데이터의 수정이 발생했을때 (c,u,d) 반영이 필요한 인덱스별로 반영 작업으로 인해 영향이 있고 내가말한건 인덱스 키 컬럼 갯수임 - dc App
@30세전에특급DBA 아 그렇구만 내가 대충얘기했구만 정정 고맙다 이기