지역, 가게업종 이라는 필드가 Read검색에 자주 사용되면
복합키로 (지역, 가게업종, 데이터 인덱스)로 만드나요
@generatrdvalue로 id 만들고
(지역, 가게업종)을 인덱스로 만드나요?
아니면 다른 방법이 있나요?
지역, 가게업종 이라는 필드가 Read검색에 자주 사용되면
복합키로 (지역, 가게업종, 데이터 인덱스)로 만드나요
@generatrdvalue로 id 만들고
(지역, 가게업종)을 인덱스로 만드나요?
아니면 다른 방법이 있나요?
일단 복합키는 미친 짓거리고요
비즈니스에서 메인이 되는 테이블을 id열로 조회할수 있는 경우도 있고 아닌 경우도 있어서 아닐때에 복합키 자주 사용함 ㅇㅇ - dc App
id열자체가 비즈니스를 가지는 경우 에 사용가능 ex) 매장번호, 순번등 - dc App
id를 복합키로 사용하다가 2정규화 만족못하는 경우 생기면 정규화 다시 함? - dc App
id를 복합키로 생성한다는 말은잘못된말임 id열은 엔티티의 속성만으로 유니크하게 레코드를 식별할 수 없을때이를 대체하여 유니크하게 정의된 열을id라고함(내가 잘못알고 있을수도 있음)정규화는 데이터 이상 현상을 방지하려고하는 엔티티 설계 방법인데이게 필수로 지켜야 되는건 아님성능을 위해서 반,역정규화 하고트랜잭션이나 프로그램로직상에서삽입이나 수정시 빡세게 체크하는 경우도더러 있음그래서 정규화를 다시 하냐고 물어보면아니라고 생각함 - dc App
일단은 내 경험상 과도하게 정규화된 테이블을 역정규화한 경험밖에없고 역정규화한 테이블을 다시 정규화한 경험은 없음 - dc App
기본키를 단일키로 사용하지 않고 복합키로 사용했을때 말한거임. 만약에 추후에 테이블 필드들이 추가가 되었고 이때 부분함수종속이 발생하더라도 정규화를 하지 않는다는거임? - dc App
넹 - dc App
메인이 되는 테이블이면 비즈니스 로직에서 탐색할 때 사용할 수 있는속성을 카디널리티가 높은순으로 복합키로 생성하고자식 테이블이면- 외래키- 부모테이블의 복합키 속성을 똑같이 속성으로 가지고 이를 키로- 자식테이블만 유니크하게 식별해야 하는경우 메인테이블하고 동일한 방식으로제일 높은 탐색경로를 가지는 속성을 먼저클러스터드 인덱스로 만들고나머지는 논클러스터드 인덱스로 만듬
*사용량이 제일 많은 탐색경로를 클러스터드 인덱스로 - dc App
답변 감사합니다. 그런데 추가적으로 "자식 테이블이면- 외래키- 부모테이블의 복합키 속성을 똑같이 속성으로 가지고" 이부분이 식별관계를 말씀하시는 걸까요
인덱스를 만들려는 테이블이 자식 테이블일 경우 내가 알고 있는 세가지 생성 케이스를 설명한건데 줄 넘기기가 적용 안됐네 첫번째케이스-외래키로만 하는거는 정규화와 정합성을 챙기는거고 두번째케이스-부모의 기본키 속성을 자식도 가지고 그를 키로하는거는 정규화와 정합성을 조금 버리는대신(프로그램단에서 귀찮아짐) 자식테이블에 대해서만 조회하는경우 성능에서 이점을 가질 수 있음 - dc App
자세한 답변 감사드립니다.
부모의 기본키 속성 + 자식테이블에서 필터링할 속성 으로 생성하는경우도 있고... 인덱스는 기본적으로 비즈니스 기반으로 생성하는거라 엔티티의 특성과 비즈니스특성별 천차 만별임 그래서 속성을 기준으로 얘기하는것 보다는 비즈니스에따라서 필터링해야할 속성을 카디널리티가 높은순으로 설계할 수 있는 인사이트가 필요함 - dc App