서론
로그에 관련된 테이블을 생성하는 과정에서 사수분에게 기능 명세 상 해당 테이블에는 PK가 없어도 될 것 같다는 말씀을 들었다.
나는 그 때 테이블에 PK가 없을 수 있다는 사실 자체를 처음 알기도 하였고, 지금까지 테이블을 설계하면서 PK가 없는 테이블을 설계 및 생성 해 본 적이 없기에 테이블에 PK가 없을 때의 장점과 단점에 대해서 한번 살펴보고자 한다.
PK가 없을 때 장점
먼저 유연성에 대해서 장점을 가질 수 있다.
PK로 지정한 컬럼은 값이 테이블 내에 유일 해야 하는 제약 조건이 붙게 된다.
만약 PK가 없다면, 여러 데이터가 중복되게 넣을 수 있고 제약조건으로부터 자유로워진다.
또 외래키 관련하여 어려움도 피할 수도있다. PK를 변경하였을 때 외래키로 연결된 다른 테이블의 FK와의 충돌을 사전에 회피할 수 있다.
마지막으로 데이터 입력 용이성이 있다.
PK 컬럼의 여러 제약 조건을 고려할 필요가 없어지기에 직접 Insert 해서 데이터를 넣기 용이하다는 것이 이유이다.
PK가 없을 때 단점
단점에 대해서 먼저 알기전에 내가 현재 사용하고 있는 InnoDB의 특성에 대해서 살펴보아야 한다.
-
Primary Key는 항상
Clustered Index이다. -
Primary Key가 없다면 아래 우선 순위로 인해서
Clustered Index가 선택된다.→ 이 말은 사실
Clustered Index가 없는 테이블은 존재하지 않는다는 말이다.- Not Null 속성의 Unique Key
- 1번의 후보가 없다면, 보이지 않는 컬럼을 내부적으로 추가해서 사용한다.
-
auto_increment 속성의 컬럼은 반드시 단일 Key 또는 복합 Key의 첫번째 컬럼이어야 한다.
위에서 나온 Clustered Index 는 데이터가 테이블에 물리적으로 저장되는 순서를 정의(설정)하며, 테이블 당 한개씩 존재할 수 있기에 테이블에서 Index를 걸면 가장 효율적일 것 같은 컬럼을 Clustered Index 로 지정해야한다.
그러면 이제 위 InnoDB의 특성을 통해 PK가 없을 때의 단점들을 살펴보도록 하자.
첫 번째론 중요한 Clustered Index 를 낭비하게 된다.
2번 특성으로 인해서 PK가 없을 경우 보이지 않는 컬럼에 Clustered Index 가 걸리게 되는데, 이는 테이블에 한 개만 생성할 수 있고, 이용할 때 가장 속도가 빠른 Clustered Index 를 낭비하게 된다.
이러한 부분은 성능적으로 굉장히 유의미한 차이점을 만들어주게 된다.
두 번째론 RDBMS의 의미가 퇴색된다.
RDBMS에서는 각 행이 반드시 고유하게 식별되어야 하며, 이러한 규칙이 보호 받지 못한다면 더 이상 RDBMS가 아니다.
세 번째론 참조를 할 수 없게 된다.
FK를 통해서 참조할 수 없게 되며, 여러 테이블들을 JOIN을 통해서 데이터를 가져올 수 없게 된다.(후보키 조차 존재 안할 때)
후기
이러한 장, 단점들을 알아봄으로써 내가 내린 결론은 “PK를 사용하자”이다.
물론 현재 기능 상으로는 사실 PK의 장점들이 굳이 필요하지 않지만, 추후 로그 테이블간의 참조 관계 등의 확장성을 고려했을 때는 필수적으로 PK가 테이블에 존재 해야 한다고 생각했다.
+무언가를 알게되었거나, 업무를 받았을 때 늘 “왜 이렇게 해야할까?”, “이렇게 했을 때의 장/단점은 무엇이 있을까?”를 생각하는 자세를 가지자.
