pk 중복 체크 프로세스

Question

데이터 등록시 중복체크가 되고 중복된 데이터가 있으면 중복알람을 띄우고 그렇지않으면 데이터를 삽입시키는 프로세스를 구현할때 보통 데이터 insert 하기전 pk 체크를 하고 체크 이상없으면 insert 프로세스를 진행하잖아요?select -> insert 총 2번의 i/o 가 발생근데 그냥 select 하지않고 바로 insert 를 해버리고 pk 오류가 나면 해당 오류 예외처리 해서 중복알림을 띄우고 pk 오류가 안나면 insert 되게 프로세스를 구현하면 문제가 있을까요? 성능적인 측면에서... 전 평소에 1번대로 구현했는데 현재 sm 하는곳에서는 다 이렇게 되어있네요.다른분들의 의견이 궁금합니다~!

르매 · Accepted Answer

PK, Unique, FK, CHECK 와 같은 것들을 선언적 무결성이라고 부릅니다. 당연히 이런 것들을 활용하는 것이 RDB 성능과 동시성 문제 해결에 가장 유리하죠.INSERT 직전에 SELECT하고 다시 INSERT를 하면, 두 번의 중복 체크가 이뤄질 뿐더러.. SELECT해서 중복을 확인한 이후 INSERT 하는 그 사이에 다른 세션에서 중복 값이 INSERT 될 수 있기 때문에 동시성 문제를 해결하지 못하는 문제도 있습니다. (이 문제를 해결하겠다고 Lock을 쓰면.. 그건 정말 최악의 선택)중복키 오류, 부모에 의한 참조 오류, 자식에 의한 참조 오류는 error no로 구분할 수 있고, 에러 메세지를 파싱하면 어느 선언적 무결성 객체에 의한 오류인지 더 세부적으로 알 수 있기 때문에 에러 핸들링에도 문제가 없습니다.특별히 선언적 무결성으로 체크할 수 없는 로직 처리에 대해서는 미리 SELECT 하는 일이 필요하겠지만 (사실 이런 일도 많이 벌어진다면 그건 설계를 제대로 못했기 때문이라고 생각하지만), 그렇지 않다면 에러를 캐치해서 핸들링하는게.. 말 그대로 베스트 프랙티스입니다.

Kunie · Answer

insert 할 때 발생하는 Excecption 이 PK 로 인한 것인지, Unique key 제약조건 때문인지, 그 외에 다른 경우인지 명확하게 구분하여 예외처리할 수 있다면 문제없을것같습니다.

잠자는사자 · Answer

생각했듯이 select안 쓰는게 좋은겁니다. on duplicate key update 쓰면 한번에 처리됩니다

yeori · Answer

select -> insert 총 2번의 i/o 가 발생정상적인 상황에서 발생할 수 있는 시나리오인지,오작동인지,...에 따라서 해결 방향이 다르겠죠.

pk 중복 체크 프로세스

4개의 답변

#pk 목록