데이터베이스 중복 데이터 방지: EXISTS 조회 vs UNIQUE 추가

[mzeong]

데이터베이스에서 중복 데이터를 방지하기 위해 EXISTS를 사용하여 조회하는 것과 스키마에 UNIQUE 제약조건을 추가하는 것 중 어떤 방법을 선택하는 게 좋을까?

[Libienz]

1안 : 스키마 상에 unique 조건

2안 : 코드 상에서 EXISTS 로 조회 후 중복 없을 시 저장

3안 : 둘다

1안 - 제리

2안 - 콜리, 리비

3안 - 에버

에버 → 제리

유니크 값이 아닐 때: DataIntegrityViolationException (Hibernate Exception)

리비

• 2안이 90% 맞다
• 중복조건은 서비스 로직이기에 변화 가능하다
  • PK : DB 특성상 중복되지 않아야 함
  • UNIQUE 조건 : 서비스 로직이 반영된 제한 조건

→ 제리

: Dto 검증 or Domain 검증은 괜찮은데 Unique 제한 조건은 괜찮지 않은 이유가 있는가?

ㄴ 에버 : Dto 에서 검증하는 것은 뷰 로직과 연관이 있는데 현재는 서비스 로직의 중복 검증을 이야기 하기에 큰 연결고리가 없다

ㄴ 제리 : 서비스 로직의 범위가 어디인가?

ㄴ 리비 : 포괄적인 서비스를 이야기하는 것이다

⇒ 도메인 제약조건은 수정이 상대적으로 어렵고, 서비스 로직은 고치기 쉽다고 생각하는 이유가 무엇인가?

→ 리비 : 유니크 제약조건은 도메인 로직이 아니다

콜리 2안으로 선택한 이유

• 서비스 로직은 서비스 클래스 안에 담겨 있어야한다.
  • 에버: 어떤 경우에 대해서도 중복되지 않는 필드에 대한 경우가 가정이기에 해당 발언은 의미할 수 없음
• 중복 검사가 필요한 서비스와 필요하지 않은 서비스가 있을 수 있음
• 즉 중복검사의 유무는 서비스에 따라 정해진다.
• 또한 fail-fast를 생각해보았을 때도 2안이 옳다고 생각
  • 에버: exist도 db를 찔러봐야 하기 때문에 failFast?
    • 콜리: 조회는 다른 개념 성능 상 차이가 있을 수 있다.
• 도메인은 중복 여부에 상관 없이 열려 있어야 한다고도 생각
• unique제약조건은 도메인 활용 범위를 낮추게 될 수 밖에 없음

제리

: 데이터 베이스의 무결성이 중요하다 → 가장 아랫단에 깨지면 안된다

: exists와 unique를 둘 다 하는 행위는 중복 검증이다

ㄴ 가장 아랫단에서 깨지면 안된다 == DB 상에서는 무결성이 깨지면 안된다

ㄴ 그 상위단에서 걸러내면 되지 않는가?

ㄴ 바로 쏘았을 때도 검증되었으면 좋겠다

ㄴ 에버 : 휴먼에러 방지에 좋다 + exists만 사용하는 것을 반대하는 이유는 무결성이 생긴다

ㄴ 리비 : 중복 코드가 휴먼에러 가능성을 높일 수 있다

리비 → 제리 : jdbc template을 사용한다고 가정하면 exception이 달라질 수밖에 없지 않는가? → 추상화나 layered architecture의 경계가 없어지지 않는가?

콜리 → 스크립트 상으로 공유되지 않은 경우 문제가 있을 수 있다.

• DB 스크립트가 공유되지 않은 경우 (개발자들간) 인지 비용 있을 수 있음
  • 제리: 스키마는 모든 개발자가 알 고 있는 것, 어떻게 모름? ㅋㅋ
• Exist는 early return, Unique는 풀 스캔
  • 제리: Unique 제약조건을 거는 순간 Unique index가 걸림

제리의 실험

배경

10만건의 데이터를 넣고

• unique를 이용한 save
• exsits를 이용한 save

⇒ unique가 빨랐다

⇒ unique가 설정과 동시에 index가 걸린다

⇒ exsits는 index가 걸리지 않는다

unique와 exists는 성능상의 이유로 결정될 수 없는 문제일 수 있다

→ 리비 : 몰라도 되는 정보가 희석되어서

→ if exists를 통한 중복 코드 → 파사드 패턴으로 극복 가능

1안 : 정합성 + 코드 생산성

2안 : 계층간의 명확한 분리 + 메서드 명세 + 추상화(하위의 예외를 알아야 하는 문제)

리비

• exsits를 쓸것
• DB는 우리가 안쓰기 때문에 UNIQUE를 안 걸어도 된다고 생각했지만, 직접 찌르면 문제가 될수 있기에 넣어도 괜찮다고 생각

제리

• UNIQUE를 사랑하지만 exists를 미워하지 않게 됨

에버

• 추상화, 메서드 명세 측면에서 Exist 쪽으로 마음이 기울 었지만 데이터베이스 무결성을 위해 둘 다 쓸 것!

콜리

• 이전에는 크게 생각하지 않았었는데 앞으로 Unique 제약조건은 필요하다고 생각하게 되었다.
• 추상적인 개념을 설명하는데 있어 스키마 만으로 엔티티를 설명할 수 있어야 한다는 측면에서 Unique 에 살짝 동의하게 됨