별개로, Unicode의 'surrogate pairs'를 조사할 때, 데이터베이스에서 'surrogate key'와 'compound primary key'에 관한 기사가 서 로게이트 연결에 걸려서 최대한 엉망이 되었어요(웃음).
데이터베이스에 익숙하지 않다면, "대체 키", "복합 기본 키", "자연 키"가 무엇인가요? ──아는 사람이 많을 테니, 제 자신을 리뷰하는 글로 요약해보려 합니다.
기본 키 (기본 키)
데이터베이스 내 대부분의 테이블에 존재하는 데이터 고유 관리 키 제약 조건입니다. 이 키를 가진 열은 중복 값(고유 키 제약 조건)을 포함하거나 빈칸(NULL)일 수 없습니다.
고유 키(고유 키, 고유 인덱스)
키 제약 조건은 중복 값이 이 키가 지정된 열에 저장될 수 없으며, 해당 열은 고유해야 한다는 점입니다. 하지만 기본 키와 달리 빈칸(NULL)은 저장할 수 있고, 중복은 빈칸(NULL)만 가능합니다. 이 키는 지정되는 시점에 인덱싱되기 때문에 고유 인덱스와 동의어입니다.
서로게이트 키스 (서로게이트 키스)
기본 키 제약이 고유 값이 부여된 열에 할당될 때 기본 키로, 이 열의 연속 숫자 수가 자동 증가 속성으로 저장됩니다. 또한 서로게이트 키라고도 불리는데, 이는 테이블 내 고유 행 레코드를 식별하기 위한 열 집합(자연 키)을 대체하기 때문입니다. 단일 열에서 모든 행 레코드의 유일성을 식별할 수 있어 체계적으로 유용하지만, 실제 서비스 등에 사용되는 데이터로서는 무의미하며, 데이터 사용자 입장에서는 데이터베이스의 물리적 저장 영역을 불필요하게 압축하는 열일 뿐입니다.
내추럴 키스 (내추럴 키스)
테이블 내 행 레코드를 식별하기 위해 고유한 키 제약을 가진 열들의 집합입니다. 예를 들어, 워드프레스에서 "게시물 ID"와 "태그 ID"의 조합이 특정 태그에 속하는 게시물 데이터를 고유하게 식별할 수 있다면, 이 두 열의 조합을 자연 키라고 하며, 그 자연 키를 가진 테이블은 'wp_term_relationships'입니다. 원칙적으로 자연 키에 포함된 열은 고유한 키 제약 조건을 가져야 하므로 종종 기본 키로 설정됩니다. 데이터 사용자의 관점에서, 의미 있는 데이터로만 고유성이 식별되는 자연 키 유형 테이블은 명확한 용도가 있으며 낭비가 아닙니다.
복합 기본 키
여러 주 키, 대리 키 + 자연 키, 그리고 기본 키 없이 다열 집합에 있는 자연 키만 있는 테이블은 복합 주 키 테이블이라고 할 수 있습니다. 간단히 말해, 단일 열로는 행 레코드의 유일성을 식별할 수 없는 테이블 유형입니다. 다른 테이블과 관련하기 위해 외래 키들의 합집합만을 관리하는 일반적인 관계 테이블 유형입니다(예: 자연키 섹션에서 소개된 워드프레스의 'wp_term_relationships' 테이블). 관계 테이블이나 DB 설계를 본 사람이라면 잘 이해할 수 있지만, 이러한 복합 기본 키 테이블은 각 외부 테이블의 대리 키가 중앙에서 관리되도록 구조화되어 있으며, 실제 데이터 간의 관계가 한눈에 명확하지 않은 경우가 많습니다. 반면, 자연 키가 기본 키인 테이블의 기본 키가 외래 키로 관련되어 있다면, 관계 표만 봐도 데이터 결합 가능성은 한눈에 알 수 있지만, 참조 비용이 높은 문자열 데이터는 데이터베이스 내에 중복되어 데이터베이스 전체의 성능 저하를 초래하고, 물리적 저장 공간에 가해지는 부담이 대체 키보다 커집니다. 또한, 특히 고유 키가 고유 식별에 관여하는 경우, 고유 데이터 처리 시스템 비용이 높아집니다.
단어를 정리하면서 복합 기본 키로 테이블을 운영하는 것이 꽤 번거롭다는 생각이 들었습니다. 사실 그건 번거롭습니다. 예를 들어, 복합 기본 키의 자연 키의 열 중 하나를 변경하려면, 행 레코드를 식별하기 위해 같은 내추럴 키를 검색 기준에 넣어야 하는데, 이 때문에 처리하는 것이 다소 번거롭습니다. 두 개 이상의 기본 키가 있는 테이블을 UPDATE하려 하면 MySQL이 화를 냅니다...
개인적인 결론은, 시스템이 사람보다 시스템이 쉽게 대응할 수 있도록 하는 것이 더 낫다는 점이며, 성능 저하를 감수하더라도 인간 측에서 데이터 가시성을 고집하는 것은 결국 끝이라고 생각합니다. 데이터베이스를 사용하는 시스템의 올바른 형태는 별도의 릴레이 처리를 만들고 인간이 쉽게 인식할 수 있도록 데이터를 구성하는 것이라고 생각합니다. 대부분의 경우, 인간이 요청하는 데이터는 시간과 사례별로 필터링되지 않으면 쓸모가 없기 때문입니다. 즉, 기본 키에 대해 복합 기본 키 대신 대리 키를 사용하는 것이 최선의 관행이라고 생각합니다.