댓글 삭제해도 답글은 남는것
유저가 탈퇴해도 글은 남는것.
이런건 어떻게 컨트롤 하는건가요 (혹은 키워드라도)
외래키 제약을 두면 안될것같고..
관계는 두되, 외래키 제약을 뺴야될것같긴한데..
어떤 키워드로 검색해봐야하는지 몰겠네요.
댓글 삭제해도 답글은 남는것
유저가 탈퇴해도 글은 남는것.
이런건 어떻게 컨트롤 하는건가요 (혹은 키워드라도)
외래키 제약을 두면 안될것같고..
관계는 두되, 외래키 제약을 뺴야될것같긴한데..
어떤 키워드로 검색해봐야하는지 몰겠네요.
chat gpt에게 물어봣을때는 걍 column을 몇개 더 추가해서 관리하라고하는데..
이게 맞는방법인진 영...
jpa라면 orphanRemoval세팅을 통해 고아데이터를 관리할 수있습니다. 하지만 제가다녀본 회사실질db관리상에서는 탈퇴등의 이슈가발생시 일반적으로 null처리를 해서 고아데이터를 안만들었습니다 - dc App
고아데이터라는 개념이 있군요. 키워드 감사합니당..
이거 보니 궁금한게있는데요. 1. 고아데이터를 굳이 쓰려는 이유는 (제가 고아데이터에 대한 개념이 없어서 그런거지만) 데이터를 어떻게든 남겨두려는건가요..? 2. 만약 1이 아니라면, 고아데이터를 삭제대신 null처리하는 이유는 외래키 제약에 따른 비용 때문에 그렇게 처리하는건가요? (뭔가 null로 변경해두는건 삭제를 시키려고 하는건데, 어쩔수없이 null로 처리하는것같아서요)
1. 고아객체라고 구글검색하셔서 읽어보시면 도움이 될겁니다. 영어를 할줄아신다면 orphan으로 검색어잡고 구글 뒤져보세용 2. 여기서 null처리라는것은 유저 테이블의 개인정보들을 말합니다 pk는 그대로유지시켜서 연관관계는 유지시키기에 고아 가 발생하지 않습니다. - dc App
그럼 제가 밑에서 이해하려고 했던 부분하고 어느정도 일맥상통 하겠네요. 고아객체를 사용하려는 이유부터 함 찾아봐야겠어요. 감사합니다. 남은 주말도 잘 보내시길 바랄게요!
다시 생각해보니, 포스트를 변경하려 하지 말고, 유저를 soft-delete처리하는것도 방법이겠군요.
Aggregate는 soft delete 처리합니다. 개인정보보호법에서 명시한건 익명화합니당 ㅇㅅㅇ
제가 선생님 말씀을 잘 이해했는지 여쭤보기위해서.. 1. 주문과 소비자 관계가 있다고 한다면, 소비자에 isDeleted같은 soft-delete를 해놓고 (aggregate에 soft-delete) 2. delete요청이 들어오면, 개인정보를 유추할 수 있는 조합에 해당하는것은 마스킹하여 업데이트한다. 맞나요?
Jpa는 안쓰지만 보통 사용하는 방법이 soft delete임
어떤 orm이든 기본적으로 지원할껄
soft-delete라는 개념에 대해서 제대로 이해하지못하고 질문한것같아요. 그럼 사실상 relation 제약은 안건드리면서 논리적 delete를 할 수 있는 방법이긴 하겠네요.
근데 soft-delete 처리라는게 성립할려면 보통 1:N관계에서 1쪽에 isDeleted라는 column을 추가 하는게 맞겠네요?
그건 어떤 테이블 구조와 로직인지에 따라 다르지. 근데 보통 N에 해당하는 데이터도 삭제해야 할 것 아님? 그럼 n에 해당하는 테이블에도 isDeleted를 추가해줘야지.
생각해보니 그러네요. 답변 감사드립니다.
orm 질문도 아닌것 같고 삭제버튼 눌렀을때 soft delete냐 아니면 제깍제깍 hard delete 하느냐인거 같은데 뭔 aggregate가 나오고 고아데이터 나오고 왜이리 어렵게 말하는거? ㅇㅅㅇ;;;
사실 질문 자체가 이해하기 어려운 상황이어서 그랬음. orm자체에 대한 이해가 낮았는데, 사용하면서 어플리케이션 레벨에서 처리할지 db레벨에서 처리해야하는건지 약간 애매했다고 해야하나.. 근데 오히려 이런 키워드를 던져줘서 더 잘 이해할 수 있었어요.
근데 궁금한게 저렇게 soft-delete로 처리하면 외래키 constraints는 orm level에서만 사실상 존재하는 개념이 되므로 db레벨에선 제거해도 됨?
orm이 insert, update, delete 체크해줄 수 있으면 굳이 외래키 제약 없어도 될것같은데 (orm을 쓴다는 가정하에서는)