[DISCUSSION] DeletedAt 컬럼 유무 (Soft 딜리트 전략)

[sweetykr7]

이슈 개요

도메인과 flyway DDL이 불일치 합니다.

도메인에 존재하는 deletedAt이 DDL에는 존재하지 않습니다.
어떤 방향으로 delete를 진행 할지에 대한 discussion이 필요합니다.

작업 목록

• �도메인과 flyway DDL 불일치 관련 Discussion

부연 설명

softDelete

현재 도메인의 softDelete에서는 status로 delete를 진행하고 있습니다.

[sweetykr7]

기존에 작업하신 분들은 이 부분을 어떻게 하시고 작업하셨는지 궁금합니다.

[github-insu]

의견: status + deletedAt
이유

• delete는 실질적으로 데이터를 삭제하는 과정이 아니므로 status로 관리하는 것이 좋다고 생각됩니다.
• 데이터 보관 관련해서 법적/정책적 보관 기간이 있다고 들은 것 같습니다. 보관 기간 이후에는 데이터를 삭제해야 한다면 deleteAt과 같은 시간이 필요로 할 것이라고 생각됩니다.
• 저희가 하는 프로젝트에서는 최대 보관 기간을 요하는 데이터가 있는지는 모르겠습니다. "관련 로직 구현이 필요하지 않을지라도 deleteAt 값을 저장은 하자. "라는게 제 의견입니다.

[shin-jingyu]

의견 : status + updateAt

• deleteAt과 updateAt이 시간을 저장하고 있으므로, status를 통해 상태를 파악할 수 있어 deleteAt는 불필요하다고 생각합니다.

[taewookimm]

의견 : status + updatedAt

• 데이터 삭제도 상태 update로 볼 수 있고, deletedAt의 데이터로 무언가의 핸들링(보안적 이슈 트래킹, 정책 이슈 트래킹, CS 등)을 하려고 한다면 borad 테이블에 컬럼을 추가하는 것이 아닌 유저가 삭제했을 때 아래 예시와 같이 저장하는 테이블을 따로 생성하는 것이 더 괜찮을 수 있다고 생각됩니다.
• ex) tb_board_delete_history -> id, userId, userIp, createdAt(deletedAt)

[merge-simpson]

제안

• Board: status + updatedAt (현재 필요한 것)
• Board 삭제 히스토리: deletedAt (이번에 구현하지 않는 것)

이유

비정규화 컬럼이라는 정체성 (해석에 따라)

각 컬럼의 역할상 이해를 다음과 같이 해석할 수도 있습니다.

• createdAt, updatedAt, deletedAt 모두 관념적으로는 그 역할이 다음처럼 비정규화 컬럼에 가깝습니다.
  • Board 생성 히스토리에 createdAt을 둘 수 있습니다. (관념상)
  • Board 수정 히스토리에서 최근 값을 updatedAt으로 둘 수 있습니다. (관념상)
  • Board 삭제 히스토리에 deletedAt을 둘 수 있습니다. (관념상)
• 이것들 중 Board에 자주 사용되는 것을 Board 테이블에 비정규화하여 담은 것과 유사한 개념입니다.
  (이것들 중 일부는 굳이 테이블로 생성하지 않습니다.)

위와 같은 이해에 따르면, createdAt, updatedAt, deletedAt 모두 필요에 따라서는 히스토리 원본 테이블을 구분할 수 있습니다.

Delete History 테이블을 구분하는 것을 선호하는 이유

위 세 컬럼 중 createdAt, updatedAt은 Board 데이터가 삭제되기 전까지로 보면, 조회 대상이 되는 '현황' Board 데이터의 필드에 가깝습니다. 하지만 deletedAt은 정책에 따라 조회 대상이 되는 '현황'에서 벗어나는 Board의 데이터일 수 있으며, 이처럼 직접 조회 대상이 되지 않는 Board 데이터를 다른 테이블로 독립시켜 기존 Board 테이블의 사이즈를 줄이는 전략을 채택할 수도 있습니다.

모든 것은 팀 내에서 협의에 따라 선택하고,
가까운 작업과 후순위 작업을 잘 구분해서 초기 전략을 채택하는 것을 권합니다.

Null 여부에 의존하는 고전 전략에서 탈피하기

많은 개발자들이 데이터의 Null 여부를 해석하여 취급하는 방식에서 탈피하고 있습니다.
null 데이터 취급을 비즈니스 로직의 각 계층에서 빈번하게 대처하는 것이 큰 불편이 되기 때문에
null 데이터는 대체값으로 표현하게 되는 가능성에 열려 있습니다.
(예를 들어 String은 "", List는 immutable empty list를 반환하는 List.of(), Collections.emptyList() 등으로 대체합니다.)

이 관점을 데이터베이스에서 데이터를 조회해 온 시점부터 적용하기를 원하는 개발자들도 존재하며,
만약 이 관점을 전체 코드에 일관성 있게 유지하려고 한다면 그들의 주장도 타당할 수 있습니다.

따라서 deletedAt 등 필드의 null 여부로 상태를 '해석'하여 의미 있는 값이나 동작을 얻는 방식에서 탈피하고,
데이터의 상태를 다소간 더 의미 있는 것으로 명시하며 다루는 것이 추후 다양한 전략적 선택지를 남겨 줄 것으로 생각합니다.

또한 데이터의 null 여부에 대해서 곧바로 대체값(optional.orElseGet(...) 등)을 사용하는 전략의 채택 가능성에도 향후 열려 있기를 바라는 입장입니다.

🚀 추가적인 피드백과 아이디어

추가적인 피드백이나 궁금한 점, 아이디어가 있는 분들은 comment 부탁드립니다. 💬

[sweetykr7]

저도 삭제시에 updateAt에는 삭제한 시간을, status에 삭제의 현황을 그리고 History table을 만들어서 삭제의 history를 볼 수 있게 하는 게 좋아보입니다.

여기서 궁금한 점이, 이런식으로 생성되는 history들이 나중에 되면 상당히 많아질 것 같은데(삭제 뿐 아니라 그 외 포함),
보통 어떤식으로 관리를 하는지 궁금합니다.

history table을 하나를 두고 type을 두고 여러 종류의 history들을 한 테이블에 관리를 하는지, 아니면 기능이 겹치는 대상들을 따로 구분하는지 등등 실제로 적용해 보신분들이 있는지 궁금합니다.

[wowddok99]

status를 따로 운영하고 있으니 삭제시에 updateAt를 업데이트 해주면 될듯합니다. 해당 이슈는 사실 최초에 flyway에는 deletedAt가 없는데 도메인쪽에 deletedAt가 존재해서 나온 이슈였습니다!

[wch-os]

현재 방식대로 status로 softe delete를, 삭제 시간은 updateAt으로 충분할 것 같습니다

[merge-simpson]

(Sub-discussion) 히스토리 테이블의 개수

이 comment의 결론: 추후 논의, 다루기 편한 방식에 초점을 둔 초기 전략, 테이블 사이즈를 줄이는 추후 전략

@sweetykr7 님께서 이 내용을 물어봐 주셨습니다.

액션마다 히스토리 테이블을 생성하면, 나중에 히스토리 테이블이 많을 것이라고 생각합니다.
따라서 다음 중 어떤 전략을 사용하는 것이 좋은지 궁금합니다.

• 하나의 history table에 action type 컬럼을 두고 여러 액션 history를 하나의 테이블에 관리를 하는지
• 액션에 따른 히스토리 테이블 분류를 하는지

자세한 논의는 on-hold 상태의 discussion 이슈를 미리 생성해 두고 추후 나눌 수 있을 것 같습니다.
(적어도 이 실습용 레포지터리에 포함하지는 않을 것 같습니다.)

---

초기 전략과 추후 전략

미리 일부 관점을 공유해 보자면 다음과 같습니다.

• 이 히스토리 테이블이 빈번하게 조회되지 않을 것으로 예상한다면, 테이블의 사이즈가 어느 정도 커지는 것은 감수할 수 있습니다.
• 그럼에도 테이블의 사이즈가 너무 커질 수 있기 때문에 각종 전략으로 테이블을 나누어 관리하는 것을 자주 찾아 볼 수 있습니다.
  • 시기에 따라, 해시 값에 따라, 액션 타입에 따라, .... 다양한 기준으로 테이블을 나눌 수 있습니다.
• 또한 추후 조회용 데이터베이스나 테이블을 구분할 수도 있습니다.

이상의 이유로 추후 다양한 전략을 고민할 수 있기 때문에, 초기 전략이 크게 민감하지는 않다는 생각입니다.
초기 전략은 다루기 편한 방식에 가중치를 많이 두고 별도 이슈로 논의해 보면 정말 좋을 것 같습니다.

---

좋은 질문 감사드립니다. 👍

[merge-simpson]

결산

충분히 아이디어가 모인 것 같습니다!

집중된 아이디어

• Board 엔티티에 status 및 updatedAt으로 삭제 상태까지 관리합니다.
• 따라서 Board 엔티티에서 deletedAt 필드를 삭제합니다.

추가적인 아이디어

• Board 액션에 대한 히스토리 테이블, 특히 삭제에 관한 히스토리를 남길 수 있는 테이블을 만들 수 있습니다.
  • 히스토리 테이블에 데이터 삭제일을 저장할 수 있습니다.
  • 이번 실습에 포함하지는 않습니다.

---

다들 좋은 아이디어 논의 감사드립니다! 👍
이 이슈도 이제 close 해 두겠습니다.

추가적인 논의가 필요하다면 이 이슈를 다시 오픈해 주세요!