게시판을 통해서도 이 부분에 대해서 몇번 언급 드린 내용인데...



PK는 물리적으로는 unique index + not null 제약조건으로 이루어집니다.


PK를 지정하면 자동으로 위와 같이 구성이 되죠. 

일반적으로 PK을 걸지 않는다는 것은 unique index + not null 을 직접 지정하여 사용하겠다는 뜻입니다.


RDB에서는 반드시 유일하게 식별할 수 있는 키로써 PK를 요구하고 있습니다.
물론 PK 대신에 unique index + not null  를 지정하여도 실재로는 동일하다고 생각할 수도 있습니다.


그러나... 여러가지 문제점이 발생합니다.

실수로 not null을 지정하지 않고 unique index만 지정할 경우 데이터 무결성이 깨지거나 성능 문제를 일으킬 수 있습니다. 칼럼이 nullable이면 인덱스를 타지 않게 됩니다.(비록 null값이 없어도 옵티마이져는 없다는걸 알지 못하므로...)


PK 제약조건은 말그대로 제약조건입니다. 오라클의 데이터딕셔너리에 저장되는 정보일 뿐이고 그 자체로 성능에 영향을 주지 않습니다.  
(오라클의 경우 딕셔너리 sys.cdef$  에 저장되는 정보입니다.)

그런데 PK를 지정하면 느리다고 주장해서 unique index + not null로 지정하는 경우도 있는데 ... 근거를 한번 제시해보라고 해보세요.


또 하나는 DBA들이 운영 관점에서 불편하다고 하여 PK를 꺼리는 경우도 있습니다.
alter table emp add constraint emp_pk primary key(empno) 등으로 처리할 경우 empno에 uk index 와 not null 이 자동으로 발생합니다.
그런데 이 경우 uk index를 nologging  parallel 처리등을 하기가 불편하니까. (enable, disable등을 할 경우 불편하니까.)   
사실 미리 create index emp_pk on emp on (empno) nologging parallel 8; 커맨드로 uk index를 생성해놓고...  alter table emp add constraint emp_pk primary key(empno) using index
해도 되지만 DBA들이 귀찮아하는 경우도 있습니다. (명령어 하나 더 쳐주기가 귀찮다라는거죠.)



저는 실수를 방지하기 위해 PK를 반드시 지정할 것을 권장합니다.  아울러 저는 FK도 참조 무결성이 중요하다면 반드시 지정할 것을 권장합니다. 
DB는 데이터규칙을 담는 그릇입니다 원래 그러한 목적으로 태어난 놈입니다. 
성능 때문이라고 주장하시는 분들께 구체적인 자료를 요구해보시기 바랍니다.
저는 실재로 부하를 측정해보았으나 미미했습니다.  참조 무결성이나 유일성 제약조건이 수행하는 Data에 대한 정합성 기능이 성능 문제를 일으키기 때문에 사용 못 하겠다는것은 참 아이러니 한 일입니다.


이 문제와 관련된 문제로

데이터에 대한 입력값 제약조건은 APP에서 하는 경우도 있고 , DB에서 하는 경우도 있을 수 있습니다.  반드시 DB에서 다 검증할 수는 없는게 분명합니다. 어떤 경우는 APP에서 검증하는게 더 좋을 수도 있습니다.
예를 들어 입력값 뒤에 붙는 스페이스 문자들의 Trim ...   
이 부분도 정책을 잘 수립해서 가야합니다.

어떤 사이트의 경우  날짜형을 varchar2로 선언해서 사용하고 있었는데,  APP에서... 날짜가 잘못 들어온 케이스가 있었습니다.  예를 들어 2006-11-33 같이 존재할 수 없는 값이 들어왔습니다.
쿼리에서는 to_date 등의 연산을 처리했으나... 11-33은 존재하지 않으므로 해당 SQL에서는 오류가 발생하였습니다. 결국 해당 업무는 서비스 불가.
따라서 제약조건 아주 중요하고 전략적으로 가져가야 합니다.