DB테이블 설계시 Primary Key 설계 관련

Question

지인 회사의 경우 DB 설계시 기본 정책이 PK는 Surrogate Key로 설계하라(그냥 자동 생성number)는 것이라고 합니다. (별도로 unique한 natural key가 있음에도 불구하고, Surrogate Key로 설계. 하지만 실제 조회/검색 요청은 해당 natural 값 위주로 요청됨) 연관관계 테이블들이 모두 PK가 surrogate key이면 surrogate key를 FK로 참조하고 있으면, 해당 실제 natural 요청 값으로 조회시 join등이 더 발생하게 될텐데요. 예를 들면, table product ( product_id bigint // Primary Key (Surrogate Key) serial_no varchar // Unique ..... ) table product_statistics ( ...... product_id bigint // FK (tb_product.product_id) ...... ) 외부에서의 product_statistics에서 각종 검색/조회/통계 요청이 serial_no 기반으로 들어오면 join 발생. 위의 예는 단순한 case지만, 현업에서는 더 복잡한 이슈가 생길 듯 한데요. 혹시 이러한 Primary Key/Surrogate Key설계와 관련해서 최근 DB 개발 트랜드/DB 개발자들의 추세 같은 것이 있을까요? 그냥 상황에 따라 다 다른 건지, 요즘은 surrogate key를 많이 사용하는 추세인지 궁금합니다.

스칼라가좋아 · Answer

https://stackoverflow.com/questions/3162202/sql-primary-key-integer-vs-varchar궁금해서 찾아봤는데 surrogate key를 사용하는게 맞는 것 같습니다. 오래 전 답변이지만 SQL 자체가 역사가 있는 셈이니 큰 변환는 없다고 생각합니다.

호칸 · Answer

PK를 Surrogate Key로 하냐 Natural Key로 하냐 하는 논란은 예전부터 많이 있었던 것 같은데, 관련해서 최근의 개발 트랜드가 있는지 저도 매우 궁금하네요. DB전문가들 계시면 답변 좀 부탁립니다. ^^ 저도 JPA 기반으로 도메인 설계할 때 많이 고민하는 부분이기도 하구요.

동쪽나무 · Answer

단순하게 어느 것이 더 좋다라고 할 수는 없을 것 같습니다. 그러나 모든 PK를 인조 식별자로 사용하는 곳은 그렇게 많지 않습니다(제 경험으로는 없었습니다).무조건 실질 식별자를 사용해야 한다. 인조 식별자를 사용해야 한다 보다는 데이터 품질, 성능, 보안 등의 이슈를 따져서 선택할 문제인 것 같습니다. 개인적으로는 특별한 경우가 아니라면 실질 식별자(natural key)를 사용하는 것이 좋다고 생각합니다.특별한 경우는- PK 구조가 다른 테이블을 한 테이블로 통합할 떄 - PK컬럼이 많아 하위 테이블로 갈수록 PK 컬럼이 너무 많아지는 경우- PK 값이 변경될 가능성이 있을 경우 등입니다. 인조 식별자(Surrogate Key)를 사용하게 되면 - 실질 식별자를 식별하지 않는 경향이 있어 중복 데이터를 양산할 수 있습니다.- 실질 식별자 속성이 하위 테이블에 없어 Nested Loops 조인시 성능문제가 생길 수 있습니다. 물론 UK를 지정하거나 로직으로 중복을 체크할 수 있으며, 하위 테이블에 상위 테이블 컬럼을 중복해서 관리하면 성능문제도 해결할 수 있습니다. 고객번호, 상품번호, 주문번호 등을 실질 식별자로 볼 것이냐 인조 식별자(Surrogate Key)로 볼 것이냐도 의견 차이가 있을 수 있습니다. 업무적으로 많이 쓰이거나 화면에 노출되는 정보는 실질 식별자로 봐야 한다는 게 제 생각입니다.

DB테이블 설계시 Primary Key 설계 관련

3개의 답변

#primarykey 목록