[CSO Project] 5 - ERD 및 또또또 고민거리

너는 바보인거냐 원호야!!!!!!!!

어제 쓴 글
https://wonowdaily.tistory.com/150

[CSO Project] 4 - 계단식 url 유효성 검사를 어떻게 해야할까?

 

진짜 안일하게 생각했다!!!!

/brand/{brandId}/category/{categoryId} 이렇게 하지말고

/brand/category/item/{itemId} 이렇게 하면 해결되는 문제잖아!!
그리고 거기에서 필요한 데이터 join 할지 안 할지 선택하는 거고..

 

근데 과연 그럴까...허허

네이버 카페로 예를 들면 게시글 조회 시 특정 카페에서

/{cafename}/{postId} 로 불러 올텐데.. 저 부분을 쓸 곳은 분명히 있긴 할 거 같다.

 

주변 고수 분도 답변을 해주셨는데

쿼리 3번날리는게 오히려 시스템에 따라 더 좋을수도잇다고 들엇읍니다.. 어플리케이션단에서 처리해야 캐싱같은걸 도입할 여지도 생기고.. 조인은 대용량 트래픽에 따라 악영향을 줄수도잇다는 이야기를 들어성..

라고 하신다.

 

진짜... 정말.. 취사의 영역... 근데.. 어렵긴 하다... 지금 어떤 레포에서는 저런 방법 쓰고 어떤 레포에서든 다른 방법 쓰고.. 계속 뭘로 정할지 딱 못정하겠음

 

거기다, 레이어 최대한 지켜보려고 repo에서 Entity 말고 dto 로 바로 받아서 반환하게 했는데

이 부분에서 n+1 문제가 계속 터진다. join, fetch join 다 써도 n+1 터짐

Entity로 받아와야 안 터진다는 답변을 지피티한테 받긴 했는데 얘는 못믿겠음

내가 진짜 잘 모르는 거 일 수도 있다. 지금 처럼 개발해본 적이 없기 때문,, 이거 jpa 공부 하고 트러블 슈팅 해야되겠음

 

허허 나는 바보다... 우하하

--------

현재 내 erd 상태는 이렇다

 

원래는 Item 에서 category fk 로 갖고 있었는데 이를 선택적 참여 관계로 바꿨다.

그리고 item 에서 brand fk 를 갖도록 했다.

생각해보면 이상하긴 했다. brand 에 너무 취우쳐서 생각하고 있었고, item이 꼭 카테고리를 만들어놔야 들어가게 하는게 맞다고 생각했었는데 지금은 아니라고 생각하고 있다. 저렇게 넣어주면 사용자가 더욱 유연하게 사용할 수 있어진다.

 

그리고 고민중인게, 질문을 받았었다. 전자제품 같은 경우 시리얼 넘버가 있을텐데 이를 하나하나 Entity로 취급해줘야 맞지 않나?

배송도 각 하나하나 마다의 객체가 배송되는게 아닌가?

라는 질문을 받았는데

 

머리가 띵했다

머리가 띵 머리가 띵

 

사실 동시성 제어 해보려구 가장 많은 예시인 수량 필드를 넣어둔건데

이 점에서 설계가 미스 난 것이다.

하나하나 관리... 점점 erd 어려워진다 허허허

 

그리고 테이블 분리가 완벽하게 이루어져있지 않다.

 

상품은 창고, 전시, 배송 등의 상태값을 가질 수 있다.

내가 여태껏 근무했던 환경을 살펴보면 창고, 전시 를 따로 나눠놓지는 않았지만 재고, 배송 이러한 상태값을 갖는 것은 분명하다.

위와 같은 문제에 대해 테이블이 나눠져있지 않다.

ENUM 으로 다 때려박으면 정규화 위반, 나중에 관리하기 더 힘들어 질 수 있다.

관리 포인트가 늘어나긴 하지만, 나눠놓는게 나중에 코드 짜기에도 더 수월하지 않을까?

위와 같은 문제는 저번 프로젝트에서 거래로직 구현하면서 심하게 느끼긴 했다. 분기점이 늘어나니, 코드가 엄청 더러워졌다, 짜기도 어렵고, 흐름을 파악하고 있는 상태에서 개발하면 괜찮은데, 흐름 놓치면 다시 잡기 힘들었다.

 

그리고 설계적으로 플로우 차트의 부재가 심하게 느껴졌다.

나혼자 개발하는 거다보니 마음이 너무 앞서서 와라라 개발하려고 했지만, 턱턱 막히니까

아 역시 문서화.. 플로우 차트..

 

이 프로젝트... 완성하기 멀어보인다...