bookstore erd v1.0
테이블 설명
쿠폰정책테이블- 정책자체를 결정함. 정액쿠폰, 정률쿠폰을 설정하고 해당쿠폰에 맞는 타입을 결정할 수 있음.
쿠폰테이블- 정책에서 발생한 쿠폰자체를 결정함
사용자쿠폰- 쿠폰테이블과 유저테이블의 관계테이블. 유저가 가지고있는 쿠폰.
카테고리쿠폰- 카테고리테이블과 쿠폰정책테이블에서 나온 관계테이블
도서쿠폰- 도서테이블과 쿠폰정책테이블에서 나온 관계테이블
문제점
-
msa 관점을 생각안하고 book api server erd와 쿠폰 erd를 관계를 만들어버림
--> 스프링 클라우드를 도입안하고 있었기 때문에 관계를 설정한 것임. -
쿠폰수량기능이 없음
--> 프로젝트 요구사항에 없어서 하지않음. -
쿠폰 발급페이지에서 발생하는 쿠폰을 어떻게 처리할것인가?
--> 쿠폰테이블은 쿠폰자체이므로 발급해주는 테이블을 만들어야 함. 그것을 생각을 못함. 쿠폰 자체가 앱에서 자동할당되는 것으로 생각함. 차후에 쿠폰 발급페이지를 만들어야 한다는 것을 생각함.
bookstore erd v2.2
테이블 설명
쿠폰정책테이블- 정책자체를 결정함. 정액쿠폰, 정률쿠폰을 설정하고 해당쿠폰에 맞는 타입을 결정할 수 있음.
쿠폰테이블- 정책에서 발생한 쿠폰자체를 결정함
사용자쿠폰- 쿠폰테이블과 유저테이블의 관계테이블. 유저가 가지고있는 쿠폰.
카테고리쿠폰- 카테고리테이블과 쿠폰정책테이블에서 나온 관계테이블
도서쿠폰- 도서테이블과 쿠폰정책테이블에서 나온 관계테이블
업그레이드 한 부분
- book api server erd와 연관관계를 끊음.
--> 스프링 클라우드를 도입하고 다시 erd를 설계함
문제점
-
여전히 쿠폰수량기능이 없음
--> 프로젝트 요구사항에 없어서 하지않음. -
쿠폰 발급페이지에서 발생하는 쿠폰을 어떻게 처리할것인가?
--> 쿠폰테이블은 쿠폰자체이므로 발급해주는 테이블을 만들어야 함. 그것을 생각을 못함. 쿠폰 자체가 앱에서 자동할당되는 것으로 생각함. 차후에 쿠폰 발급페이지를 만들어야 한다는 것을 생각함.
bookstore erd v3.0
테이블 설명
쿠폰정책테이블- 정책자체를 결정하고, 정책사용여부를 통해 정책 폐지를 할 수 있게 함.
카테고리쿠폰- 카테고리 관련된 내용(id, name)을 가지고 있는 테이블, 쿠폰정책과 1:1 관계
도서쿠폰- 도서 관련된 내용(id, title)을 가지고 있는 테이블, 쿠폰정책과 1:1 관계
사용자쿠폰- 쿠폰 정책으로 부터 바로 사용자 쿠폰이 발생하게 함. 해당 정책에 해당되는 쿠폰을 유저가 갖게됨.
쿠폰 템플릿- 쿠폰템플릿은 쿠폰 발급페이지에서 볼 수 있는 유저가 발급받을 수 있는 쿠폰. 쿠폰 수량기능을 넣음으로써 유저가 받을 수 있는 쿠폰이 제한됨.
업그레이드 한 부분
-
카테고리쿠폰, 도서쿠폰 테이블의 카테고리이름, 도서제목필드를 추가함
--> 도서, 카테고리 테이블에서 값을 가져와서 쿠폰 정책을 추가할때 해당 카테고리쿠폰, 도서쿠폰 테이블에 정보를 넣어줌. 따라서 차후에 쿠폰정책을 조회할때 카테고리쿠폰, 도서쿠폰만 조회하면 해당 정책에 대한 도서, 카테고리 정보를 얻어올 수 있음. -
쿠폰템플릿 테이블을 추가함.
--> 유저가 발급받을 수 있는 쿠폰발급페이지의 기능을 수행할 수 있게 됨. 또한 수량도 추가함으로써 쿠폰발급 통제가 가능함. -
쿠폰정책테이블에서 정책사용여부 필드를 추가함
--> 정책사용을 폐기할경우 다시 해당정책을 사용할 수없게끔 조치함. 정책을 삭제하는 것이 아닌 폐기여부를 도입해서 쿠폰 정책 페이지에서 폐기로 나오게끔 할 수 있음. -
사용자쿠폰테이블을 다시만들고 기존 사용자쿠폰 테이블에서 쿠폰만료일, 쿠폰발급일 필드를 추가함
기존 사용자 쿠폰은 쿠폰과 유저의 관계에서 나온테이블임. 쿠폰과 book api server는 서로 다르기때문에 연관관계를 제거하고 보면 결국에 쿠폰의 본질인 유저에 대한 쿠폰테이블 하나만 필요할 것이라고 생각함. 따라서 기존 쿠폰 테이블과 사용자쿠폰을 합침. 정책과 사용자쿠폰은 1:N관계를 맺음.
문제점
- 쿠폰테이블을 제거함
--> 쿠폰자체의 역할이 사라짐. 사용자쿠폰이 쿠폰자체의 역할을 하기에는 너무 디테일한 부분이 있음. 이 부분은 많은 고민을 했으나 해결하지 못함.
왜냐하면 프로젝트 마감기한이 2주앞으로 남은 상황에서 testcode, validation, error처리등을 할려면 시간이 너무부족해서 더이상의 erd변경은 무리라고 생각했음.
느낀점
쿠폰자체의 역할을 하는 쿠폰테이블과 사용자쿠폰테이블의 역할을 다시 이해하고 이 부분을 고민해봐야 할 것 같다.
그리고 erd를 짜면서 느낀점은 비즈니스로직에서 쿠폰정책, 템플릿, 사용자쿠폰에 대한 crud를 처리하는 방식과 db상에서 데이터를 어떻게 가져오는 것이 효율적인지를 끊임없이 고려해봐야 한다는 점이었다. 따라서 비즈니스 로직을 실행할때마다 log를 보면서 쿼리를 어떻게 날리는지, N+1문제가 발생하는지 이런 것들도 생각해봐야 할 것같다.
