DB 모델링 피드백 반영

[inkyu0103]

설명

DB 모델링에 관해 받은 피드백을 정리하고 반영합니다.

1. Brand는 enum일 필요가 없는가?

어떤 브랜드가 들어올지 몰라서 일단 string 값으로 받고, 윤곽이 정해지면 그때 enum으로 할 생각이었다.

-> 브랜드 정보가 단순히 라켓에 종속된 내용이 아니라, 의류, 신발 등에서도 사용되는 개념이어서 별도의 테이블로 빼는 것으로 결정!

2. weight 단위가 모두 U로 통일된다면, Int로 저장하는게 낫지 않을까 (U가 계속 붙으면 불필요한공간 낭비)

enum 타입을 쓴 이유는 weight 필드에 다른 값이 들어가는 걸 막는게 좋다고 생각해서였는데, 요건 postgresql 공식 문서를 읽어봐야겠다.

개인적으로, enum을 그대로 사용하도록 하는 것이 좋다고 생각함. (뇌피셜 가득)

• 일단 라켓에 들어갈 row가 아무리 많아도 300개를 넘지 않을 것으로 예상
• 레코드 수가 적기 때문에, 불필요한 공간을 조금 더 사용하더라도, type safe한 값이 들어가는 것이 더 나아보임.

2-1. enum은 내부적으로 int 형식이 아닌지?

맞음.

enum RacketWeight{
   W3U
   W4U
   W5U
}

로 해도 저장될 때는 내부적으로 Int로 저장한다고 함

3. 테이블의 pk를 그냥 id로 하는 건 어떤지?

테이블의 pk 이름을 userId 처럼 table명 + id 로 설정한 이유는, FE 에서 여러개의 api를 호출하고, id 정보를 모두 사용해야 하는 경우가 있다.

// users
[
   {
      id:1,
      name:'inkyu',
      ...
   },
   {
      id:2,
      name:'inkyu',
      ...
   },
]  

// rackets
[
   {
      id:1,
      name:'racket1',
      ...
   },
   {
      id:2,
      name:'racket2',
      ...
   },
] 

그러면 id라는 변수명이 겹치기 때문에, 일일히 변수에 alias를 달아줘야 하는 불편함이 생기게 된다.

아직은 그런 경우가 없긴 하다.

id 로 바꾸려고 하는 이유는 다음과 같다.

• 컨벤션이 그러함
• 필요하면 ORM단에서 변경 가능

수정된 모델링

[inkyu0103]

반영완료한 이슈입니다.