오늘도 역시나 이력관리에서 배움이 있었고, 추가로 소프트 delete에 관해 좋은 아이디어를 얻었다.
기존의 상품 정보 테이블은 하나의 상품에는 하나의 상품정보가 있다고 가정하고 만들었었다. 그런데 상품 정보가 수정될때마다 새로운 상품 정보 테이블을 만들어 관리하려다보니 pk인 상품 아이디 값이 계속 바뀌어서 결국은 특정 상품 아이디의 이력을 관리하는게 불가능해졌다.
이를 막기 위해 상품 아이디만을 관리하는 테이블을 따로 만들어서 이력이 변해도 영향을 받지 않게 하고, 계속 생성되는 상품 정보 테이블이 이 상품 아이디 테이블을 참조하게 만들어서 이력을 관리할 수 있게 했다.
두 번째로는 소프트 delete. 실무에서는 거의 모든 데이터를 보관해두고 문제가 있을 때 이력을 확인해봐야한다고 한다. 그래서 UI 측면에서 데이터가 삭제된 것처럼 보여도, DB에서는 기록을 남겨둬야하는데, 이때 소프트 delete의 방식을 취한다. 이 방법을 사용하기 위해 모든 테이블에 'is_deleted'라는 필드를 추가하고, 삭제되기전에는 0의 값을, 삭제가 된 후에는 1을 주는 방식으로 테이블을 설계했다.
이커머스 쪽에서 일했던 경험이 있어서 도메인 지식이 어느정도 있는 편인데도 개발 실무에 들어와보니 기존 생각과 다르게 돌아가는 부분이 많이 보인다. 이래서 실무 경험이 중요하다고 하는건가~~