db 구조 고민 + int와 char 탐색속도에 대해...

Question

안녕하세요! db구조에 대해 조금 고민이 생겨 질문드립니다.테이블 A - Aid(pk), userid(fk), name테이블 B - Bid(pk), userid(fk), Aid(fk), name2이렇게 구성된 테이블이고, A와 B는 일대다 관계입니다.근데 이렇게 구성해도 되지 않을까 싶은데, 뭐가 더 나은지 판단해주시면 감사하겠습니다테이블 A - userid(pk, fk), name(pk)테이블 B - Bid(pk), userid(fk), name(fk), name2직관적인건 후자인데, int/char 탐색속도 차이나 관리 측면에선 전자가 더 나을 것 같고 고민되네요....CRUD는 A테이블에서 거의 안하고 (분류하는 역할만 하는거라) B테이블에서 많이 수행될 거예요.

르매 · Accepted Answer

이것 만으로 어느 쪽이 좋다고 말씀드리긴 어렵습니다만, 대개 첫 번째 방식을 선택하는 것은 맞습니다.첫 번째 방식을 선호하게 되는 이유는조인 문이 간결하다.PK의 사이즈가 작아 참조하는 테이블의 공간이 절약되고 I/O에서 유리하다.만약, A 테이블을 참조하는 테이블이 없다면 user_id, name으로 PK를 잡는 것이 전혀 문제가 되지 않구요. 다른 테이블에서 참조할 때.. 복합키를 FK로 참조하는 것이 위와 같은 이유로 부담이 되는거죠.다만, 특수한 상황에서는 일부러 복합키로 PK를 만들어서 다른 테이블이 참조하게 하는 경우도 있습니다.예를 들면 B 테이블을 조회할 때 A.name 컬럼 만 추가로 필요한 경우가 빈번하다면, A 테이블과 조인하지 않아도 되서 유리하다던가.. 하는 것들입니다.하지만.. 특별한 이유가 없다면 첫 번째 방법이 좋습니다. 두 번째 방법은 점점 후회가 밀려오는 경우가 많아서요 ㅎㅎ결론A 테이블을 참조하는 다른 테이블이 있다면 A 테이블의 PK는 복합키로 설정하지 않는다.다른 테이블이 참조하지 않는다면 복합키로 설정하는 것이 오히려 권장되지만, 이건 개발이 진행되어도 여전히 그럴 것이라는 확신이 필요하다.A 테이블을 참조하는 다른 테이블이 있더라도 특수한 필요에 의해 PK를 복합키로 설정하는 것을 고려해 볼 수 있다. 하지만, 이런 경우는 매우 매우 드물다.

잠자는사자 · Answer

당연히 전자입니다. 후자처럼 하는게 시스템 망치는 사람입니다.

초무쿤 · Answer

대리키(Surrogate Key)와 자연키(Natural Key) 차이인듯 보이는데데이터의 특성에 따라 다릅니다.(속도는 느낄수 있을 정도인지는 글쎄요. 성능측면 보다는 논리모델로 접근하는게 맞을거 같아요.)ps. 전자정부프레임워크가 욕도 많이 먹지만 그래도 오랜 노하우가 녹아있고 전문가들이 검수한 모델이라 ERD모델을 한번 참조해보시면 도움이 되실듯 합니다. 저도 고민될때 가끔 들어가서 어떻게 풀었는지 참조하는 편이라..

db 구조 고민 + int와 char 탐색속도에 대해...

3개의 답변

#pk 목록