태그-실수 연관관계 hard delete VS soft delete

[gorapaduckoo]

현재 상황

• 태그 N : N 실수, 다대다 연관관계 테이블이 있어요.

• soft delete 전략을 사용하고 있어요. 실수나 태그 삭제 시 deleted_at 컬럼이 업데이트돼요. 하지만 연관관계 테이블의 데이터는 삭제하지 않았어요.
  태그를 조회할 때 실수의 개수 mistakeCount도 List.size() 로 함께 조회해서 반환해줬는데, 그 결과 삭제된 실수의 개수까지 카운팅되는 문제가 발생했어요.
  

고민되는 부분

• 아래 방법들 중에 어떤 게 더 좋을까 고민중이에요!
• hard delete 채택하기: 태그나 실수를 삭제할 때, 연관관계 테이블의 데이터까지 삭제하는 방법이에요. 이렇게 하면 기존의 코드를 크게 수정하지 않아도 되고, 태그나 실수를 조회할 때 쿼리를 통해 삭제된 데이터인지 추가로 검증하지 않아도 돼요. 하지만 어떤 태그가 많이 할당됐는지 등에 대한 통계 정보를 제공하기 어려워진다는 단점이 있어요.
• soft delete 채택하기: List.size()로 단순하게 조회하지 않고, 리스트에 담긴 객체의 삭제여부를 전부 검사하거나, 별도의 조회 쿼리를 날리는 방법이에요. 이렇게 하면 기존 코드를 많이 수정해야 한다는 단점이 있어요. 하지만 저희가 사용중인 soft delete에 어울리는 방법이고, 데이터를 보존하기 때문에 휴지통 등의 기능을 추가할 때 문제가 발생하지 않는다는 장점이 있어요.
  • 테이블 설계 변경하기: 가장 기본적인 해결 방법으로, 태그 - 실수 연관관계 테이블에도 deleted_at 컬럼을 추가하는 방법이에요. 하지만 이렇게 되면 태그를 할당 해제했다가 재할당하는 경우, 어떻게 처리할 것인지에 대해서도 결정해야 해요. 또 사이드 이펙트가 크다는 단점이 있어요.
  • 코드를 통해 삭제 여부 확인하기: 테이블 설계를 변경하지 않고, 로직을 통해 해결하는 방법이에요. 사이드 이펙트가 상대적으로 적지만, 매 연산마다 오버헤드가 커질 수 있다는 단점이 존재해요.

멘토님의 코멘트

[gorapaduckoo]

• 연관관계를 hard delete 하는 경우, 어떤 태그가 많이 할당됐는지, 사용자가 어떤 태그를 많이 사용했는지 등에 대한 정보를 알 수 없게 될 것 같아요.
• 태그는 사용될 때 의미가 있지, 단순히 생성하는 것만으로는 큰 데이터적 의미가 없다고 생각해요. 그런 점에서 연관관계를 hard delete하면 태그를 soft delete하는 의미가 없지 않나 싶어요🤔
• 개인적으로는 soft delete가 낫다고 생각해요! 실수 수정 기능이 없어서 soft delete를 유지한다고 해도, 사이드 이펙트가 생각보다 크지 않을것같아요.

[woodowoon]

soft delete 가 좋다고 생각했습니다.

고민이 되었던 부분은 비지니스 로직을 통해서 deleteAt 가 null 인지 아닌지 체킹을 하게된다면 너무 많은 데이터를 체크하게 되는 것이 아닐까 하는것이 고민이었습니다.

하지만 논의 결과 쿼리를 이용하게 된다면 JPA 영속성 컨텍스트로 불러온 객체들의 deleted 여부를 일일히 검사하는 것이 아니라 DB 에 있는 데이터를 걸러서 조회할 수 있기때문에 고민했던 부분들이 해결되면서 soft delete 가 좀 더 나은 설계 방법이지 않을까 생각하게 되었습니다.

현재 개발된 기능들로는 테이블 설계 없이 충분히 커버할 수 있지만 테이블 설계를 변경하는 것이 더 맞다고 판단된 이유는?

• 현재 soft delete 를 이용하여 실수와 태그를 삭제하고 있는데 연관관계 테이블을 hard delete 하게된다면 테이블 간의 데이터 불일치 문제가 걱정 되어서 변경하기로 하였습니다.
• N:N 관계로는 추후에 기능 개발에 걸림돌이 될 것 같다는 생각에 장기적인 관점으로 보았을때 변경하기로 하였습니다. (휴지통 기능, 태그&실수 수정 기능 등)

[gorapaduckoo]

테이블 설계를 변경한다면?

• deleted_at 컬럼을 추가하려면, 다대다 연관관계 테이블을 다대일 - 일대다 테이블 2개로 분리해야 할 것 같아요.
• 태그 생성, 실수 생성: 그대로 연관관계만 추가해주면 될 것 같다.
• 태그/실수를 삭제했을 때
  • 태그/실수의 deleted_at 컬럼을 업데이트한다.
  • 연관관계 테이블의 deleted_at컬럼도 업데이트한다.
  • 태그에 속한 실수의 개수를 불러올 때는, List.size()가 아니라 쿼리를 날려서 DB에서 직접 조회해오는 걸로 바꾼다.
  • 실수에 할당된 태그들의 개수는 이미 DB에서 직접 조회해 오는 중이므로 큰 문제가 없을것같다.

[gorapaduckoo]

테이블 설계를 변경하지 않는다면?

• 현재 상태로는 사용자가 실수에 할당된 태그를 할당 해제할 수 있는 방법이 없기 때문에 테이블 설계를 변경하지 않고, 실수 개수만 DB에서 직접 조회해오는걸로 바꾸는 방법도 가능해요.
• 만약에 추후에 할당된 태그를 할당 해제할 수 있게 만들고 싶다면, 테이블을 분리하고 가는 것도 괜찮을 것 같아요.
• 하지만 그런 기능을 넣을 생각이 없다면, 지금은 사이드 이펙트가 크기 때문에, 테이블을 분리하지 않고 List.size() 부분만 수정하는 것도 괜찮다고 생각해요.
• 연관관계의 삭제를 어떻게 볼 것인가에 따라 달라질 것 같아요.
  • 저는 태그와 실수의 연관관계를 삭제한다면 그건 실수에 할당된 태그를 할당 해제하는 거라고 생각했어요. 회원 탈퇴 시 회원 데이터는 지워도 회원이 작성했던 실수와의 연관관계를 삭제하지 않는 것처럼, 실수 데이터를 지워도 태그들과의 연관관계는 삭제되지 않아야 한다는 의미에요.
  • 매니님께서는 태그/실수 데이터를 삭제할 때 실수/태그와의 연관관계도 삭제하는 게 맞다고 보셨어요. 데이터를 지우면 관련된 연관관계도 다 끊어줘야 한다는 의미에요.

[gorapaduckoo]

@cottonpup @seovee
프론트 분들의 의견도 궁금합니다! 실수에 할당된 태그를 변경할 수 있도록 하는 것에 대해서 어떻게 생각하시나요? 예를 들어, 회사 태그, 개발 태그가 할당되어 있던 실수에서 개발 태그는 할당 해제하는 케이스요.

이전에 이 기능이 실수 수정에 해당하는 것 같다고 구현하지 않기로 했었던 걸로 기억해요. 하지만 현재 테이블 설계는 확장에 제한이 많은 상태라서 추후 추가적인 기능(ex: 태그 관련 통계 제공)을 도입하는데 많은 제약이 따를 것 같아요. 수정할거면 지금 수정하고 가는 게 깔끔할 것 같아서 한번 더 여쭤봐요🥹 comment 말고 reply로 의견 달아주세요!

[seovee]

벨로그처럼 할당 해제/등록 하는 기능이 당연히 있으면 너무 좋을거같아요.
그런데 테이블 설계에 어려움이 있는 상황이면 변경하지 않는 방법으로(백엔드분들 편한방법)으로 먼저 하는게 좋을거라 생각합니다!!

[gorapaduckoo]

그럼 일단은 프로젝트 완성에 중점을 두고, 수정 기능 없이 DB 설계 그대로 가져가는걸로 할게요~!