Soft Delete vs Hard Deletesoft delete(논리 삭제)실제 데이터를 삭제하는게 아니라 삭제용 칼럼을 두고 그 값을 변경해서 논리적으로 삭제를 구현하는 방식이다주로 isDeleted와 같은 boolean 필드를 만들거나 삭제 날짜 필드를 사용한다장점데이터 복구에 용이하다삭제된 데이터 이력을 유지할 수 있다관련 데이터의 참조 무결성을 유지하기 쉽다실수로 영구적 데이터 손실을 방지할 수 있다단점데이터베이스 크기가 계속 커진다인덱스 효율이 떨어질 수 있다실제 삭제를 위한 추가 작업이 필요할 수 있다hard delete(물리 삭제)실제 데이터를 테이블에서 삭제하는 방식이다장점데이터베이스 크기를 효율적으로 관리할 수 있다쿼리가 단순하고 직관적이다일반적으로 데이터베이스 성능이 더 좋다단점삭제..
개인 프로젝트에서 엔티티 간의 관계를 다루면서 지연 로딩과 프록시를 조금 더 이해할 수 있는 순간을 경험했다. 프로젝에는 Match 엔티티는 inviter라는 Team 엔티티와 관계를 맺고 있다. 이 관계는 지연 로딩으로 설정되어 있다. 매칭을 수락하는 로직이 있는데 여기서 매칭을 보내온 inviter의 현재 상태를 확인해야 했는데, 여기서 생각과 다른 상황이 발생했다. matchValidator.validateTeamStatus(match.getInviter().getStatus()); 위 코드가 그 상황이다. 지연 로딩을 사용할 때 조회되지 않은 엔티티는 프록시 객체 상태라는 개념은 알고는 있었다. 그리고 해당 엔티티가 필요한 순간에 조회 쿼리가 나간다는 사실도 알고 있었다. 그렇지만 정확히 어떤 ..
이슈 정리 주문 관리 api를 만드는 중 등록 된 주문을 조회할 때 json이 거의 무한 반복으로 나왔다. 테이블 관계 때문에 쓴 @ManytoMany, @OneToMany 같은 관계 때문인가라고 고민해 보았다. { "products": [ { "id": 1, "name": "치즈버거", "description": "패티, 치즈", "price": "4000원", "stock": 9, "createdDate": "2022-02-25T00:00:00", "modifiedDate": "2022-02-25T00:00:00" }, { "id": 2, "name": "빅맥", "description": "시그니쳐 버거", "price": "6000원", "stock": 10, "createdDate": "2022..
