• 카테고리

    질문 & 답변
  • 세부 분야

    데이터베이스

  • 해결 여부

    해결됨

limit offset 단점

23.08.03 01:02 작성 23.08.03 01:31 수정 조회수 219

0

안녕하세요 제로초님.
항상 질 좋은 강의 감사합니다.

offset 방식으로 pagination 구현 시 데이터가 누락될 수 있다는 단점을 설명해주시면서

soft delete 방식으로 구현 시에는 해당 이슈가 괜찮다고 설명해주셨는데요.

soft delete 방식으로 구현 시에도 동일한 이슈가 발생할꺼라는 생각이 들어 질문을 남깁니다.

soft delete 방식으로 구현 시에도 조회 쿼리를 날릴 때, deleteAt이 null인 값인 data들은 filter 되기 때문에 동일한 이슈가 발생할꺼 같은데 맞을까요?

추가로 삭제 연산을 soft delete 방식으로 구현 시,
on delete option을 "casecade"로 설정했다면 부모 row가 삭제되었을 때, 자식 row도 soft delete 처리가 되나요?
아니면 set null 방식으로 처리가 되나요?

답변 1

답변을 작성해보세요.

1

아, soft delete 때도 동일한 문제가 있을 것 같긴 하네요. 일단 where를 거는 순간 offset 방식은 놓치는 데이터가 생길 수밖에 없습니다.

soft delete는 실제로 지우는 행위가 아니라서 자식 row에는 아무 일도 일어나지 않습니다.

Dev님의 프로필

Dev

질문자

2023.08.03

soft delete는 실제로 지우는 행위가 아니라서 자식 row에는 아무 일도 일어나지 않습니다.

그렇다면, soft delete 구현 시 데이터 정합성을 지키기 위해서, 코드단에서 따로 로직을 추가하는 방식이 이루어지나요?
soft delete 구현 시 데이터 정합성을 위해 어떤 방식을 주로 사용하시는 지 궁금합니다.

답변 감사합니다 :)

soft delete에서는 아무것도 하지 않아도 데이터 정합성이 지켜집니다. 데이터 정합성은 foreignKey가 있는데 원본은 존재하지 않거나 할 때 깨지는 것인데 soft delete는 그냥 deletedAt 컬럼에 시간이 들어가있을 뿐이라 바꿔야할 게 없습니다. 다만 이제 그 키를 외래키로 참조하는 자식 테이블들은 부모의 deletedAt이 null인지를 체크하면서 가져와야겠죠.