초기 DB 스키마 결정

[juyohan]

DB 스키마 (초기스펙)

[philipjkim]

@juyohan @kimdg1105 두분다 늦은시간까지 고생 많으셨고, 스키마 잘 잡아주셨네요~

테이블명이나 컬럼명의 convention 에 대해서도 간략히 정하고 가면 좋을거같은데요, 제가 현업에서 사용하는 convention 을 몇가지 공유하자면:

1. table 명, column 명 모두 소문자, snake_case ( camelCase 아님) 로 한다.
2. table 명은 복수로 한다. (ex: entity 가 Team 이면 table name 은 teams, entity 가 Person 이면 table name 은 people)
3. 모든 테이블의 PK 는 auto-incremented int 로, 이름은 id 로 통일한다.
4. varchar size 는 보통 2^n -1 또는 2^n 으로 하는데 요즘은 2^n 으로 잡는 추세 (많이 쓰는 값들: 16, 256, 1024, 4096), 더 큰 바이트로 잡아야 한다면 varchar 보다는 BLOB 이나 TEXT 사용

위에 말씀드린 4가지 정도는 초기에 미리 개비하고 시작해도 좋겠네요.

[philipjkim]

label 에 db, infra 추가했고, db 레이블링했어요. 그리고 이슈를 주로 다루는 분이 꼭 assign 해주세요~

[juyohan]

@kimdg1105 하나의 드래프트 안에서, 한명의 유저는 여러명의 player를 가질 수 있지만, 한명의 선수는 여러명의 user를 가질 수 없다. 를 기준으로 한번 더 생각을 해봤습니다. 그래서 여러 드래프트들을 모아주는 테이블을 만들어서 관리를 해주면 어떨까? 라는 생각을 가지고 테이블을 추가를 했고, 각 드래프트마다 고유번호를 지정을 해주고 연관관계를 통해 지속적으로 관리가 가능할 것 같습니다! 그래서 이렇게 변경했는데, 보시고 의견 달아주세요!!

@philipjkim 각 사용자의 이름과 카카오 로그인을 통해 받아오는 이름은 한글이니 varchar 보다는 저장공간이 살짝 더 크긴 하지만, 유니코드를 지원하는 nvarchar 이 좋을 것 같아서 사용을 했습니다. 그리고 각 사이즈는 영문으로 각 1바이트씩이니 n^2 값으로 지정을 했는데, 사이즈 확인 좀 부탁드리겠습니다!

[philipjkim]

@philipjkim 각 사용자의 이름과 카카오 로그인을 통해 받아오는 이름은 한글이니 varchar 보다는 저장공간이 살짝 더 크긴 하지만, 유니코드를 지원하는 nvarchar 이 좋을 것 같아서 사용을 했습니다. 그리고 각 사이즈는 영문으로 각 1바이트씩이니 n^2 값으로 지정을 했는데, 사이즈 확인 좀 부탁드리겠습니다!

유니코드, 더 정확히는 utf8mb4 를 사용하려면 db 와 table 생성시 charset, collation 을 그에 맞게 지정해주면 굳이 nvarchar 를 사용하지 않아도 될것같고, mysql 기준으로는 varchar 가 바이트 기준이 아닌 글자수 기준이라 varchar 로 쓰는게 일반적이라 알고있어요. 이 부분은 확실하게 알고싶으시면 구글링해서 알아보시고 여기에 공유해주심 조을듯요.

[juyohan]

@philipjkim 당연히 바이트수 인 줄 알았는데, mysql 4.1 이상부터는 varchar가 바이트 기준이 아닌 글자수 기준이네요! 가장 중요한 부분을 놓치고 있었네요;; 다시 길이를 조절을 시키겠습니다! 감사합니다.

nvarchar 같은 경우엔, varchar과는 다르게 유니코드 문자열로 한글이든 영어든 모든 글자에 따라 바이트의 수를 2바이트로 고정을 시켜서 사용을 합니다. 따라서 varchar 같은 경우에 8000자를 넣을 수 있다면 nvarchar 같은 경우엔 4000자를 넣을 수 있다고 합니다. 만약 이모티콘이 아닌 한글만을 사용을 한다면, utf8mb4 (한글 1글자 = 3byte) 의 character set을 사용하는 것보단, nvarchar 나 euckr (한글 1글자 = 2byte) 을 사용하는게 더 좋다고 합니다.

결론, 가장 간편하게 utf8mb4 charater set을 사용해서, varchar로 통일해서 사용하는게 좋을 것 같다. 하지만, 데이터를 더 구두쇠처럼 다둘려면 nvarchar나 euckr의 charater set을 사용하는게 좋을 것 같다.

[philipjkim]

결론, 가장 간편하게 utf8mb4 charater set을 사용해서, varchar로 통일해서 사용하는게 좋을 것 같다. 하지만, 데이터를 더 구두쇠처럼 다둘려면 nvarchar나 euckr의 charater set을 사용하는게 좋을 것 같다.

업계 표준이 varchar 이고, 우리가 지금 데이터 컴팩션에 집중할 하등의 이유가 없으니 전자로 고고~

[juyohan]

테이블

users

user_name : 드래프트를 입장 했을 때, 사용할 이름 kakao_key : 카카오 인증을 통해 사용자 고유 id로 저장여부를 확인 kakao_name : 카카오에서 사용하고 있는 이름 (안가져와도 그만이긴 함..) user_budget : 사용자가 가지고 있는 총 금액

authorities

authority_name : 권한 이름

bidders

selected_num : 드래프트 내에서 선수가 뽑힌 순서 player_payment : 선수를 입찰한 금액

players

player_name : 선수의 이름 player_position : 선수의 포지션

player_stats

player_3pt : 3점 성공률 player_fg : 슛 성공률 player_ft : 자유투 성공률 player_pts : 총 득점 player_reb : 리바운드 개수 player_ast : 어시스트 개수 player_st : 스틸 개수 player_blk : 블락 개수 player_to : 턴오버 개수 player_td : 트리플 더블 개수

players_status

enable : 입찰이 된 여부

teams

team_name : 팀 이름

matches

match_date : 경기 일자

auctions

auction_key : 드래프트 룸의 고유 키 auction_name : 드래프트 룸의 이름 (없어도 된다.)

연관관계

users(1) ←→ bids(N)

한명의 유저는 여러번의 입찰을 할 수 있음. 예 ) user1 : james, young, davis

users(N) ←→ authorities(M)

한명의 유저는 여러개의 권한을 가질 수 있고, 여러명의 유저는 같은 권한을 가질 수 있음. 예 ) user1 : admin, user user2 : user

bids(1) ←→ players(1)

한번의 입찰에선 한명의 선수만 할 수 있음. 예 ) user1 : james user2 : james(x)

bids(N) ←→ actions(1)

1개의 드래프트 내에서 여러개의 입찰 정보를 가질 수 있음.

players(1) ←→ player_stats(N)

한명의 선수는 여러개의 스탯을 가질 수 있음. 예 ) 7일의 경기를 한다면, 7일에 대한 스탯이 들어감.

players(N) ←→ teams(1)

한개의 팀엔 여러명의 선수를 가질 수 있음. 예 ) ATL : young, collins, bogdanovic

players(1) ←→ players_status(1)

한명의 선수는 하나의 상태를 가질 수 있음. (상태를 정의) 예 ) james : false collins : true

teams(1) ←→ matches(1)

각 경기에서 여러 팀들 중에서 한팀(home_team)과 한팀(away_team)이 경기함. 예 ) ATL vs LAL

@kimdg1105 고민 더 해보고 추가해보고 정리를 해봤는데, 괜찮을까요?😅 너무 멋대로 막 바꾸고 그래서 죄송합니다..!😭

[kimdg1105]

@kimdg1105 고민 더 해보고 추가해보고 정리를 해봤는데, 괜찮을까요?😅 너무 멋대로 막 바꾸고 그래서 죄송합니다..!😭

변경 내용 확인했습니다. 테이블과 컬럼명 네이밍 컨벤션 수정되고 더 명확해진 것 같아서 좋네요 ㅎㅎ 몇가지 의견 공유드립니다!

• users 테이블

  1. 말씀대로 카카오 닉네임이나 유저 네임 중 하나를 사용하는 것으로 정의하고 user_name / kakao_name 중 하나는 없어도 될 것 같습니다.
  2. user_budget : 매 드래프트마다 200 값이 부여되고 차감 되는 방식일텐데, 유저 고유 정보를 관리하는 목적의 users 테이블에 있는 것보다 autions 테이블과의 관계를 맺어 로그용 테이블을 두고 유저마다 금액이 찍히게 관리해도 좋을 것 같아요.

• bids 테이블

  1. 유저들이 '입찰'을 한 로그가 쌓이는 방식이 아닌 '입찰 완료'된 선수들만 저장되는 테이블로 저희가 그 때 아이디어를 공유한 것 같은데, 만약 '입찰' 내역이 매번 찍힌다면 (동규 - 르브론 1$, 요한 - 르브론 3$ , 동규 르브론 5$ ...) 테이블 관계 설정을 bids -Player 도 1:N으로 는 방법도 있을 것 같아요. * 야후 드래프트 결과 기능 중에 선수의 비딩 로그를 보여주는 부분이 생각나서요!
  2. Player_status 관리 테이블도 입찰된 선수를 구분짓는 용도로 저희가 생각을 했는데, bids 테이블 로우에 'where player_id =? and select_num is NULL' 로 그 기능을 할 수 있을 것 같다고 생각됩니다. 이 방식을 어떨까요?

• authorities 테이블에 있는 '권한'의 의미는 어떤 것일까요?

---

@juyohan
플레이어와 팀, 매치 테이블은 저번 미팅 때와 동일한 것 같네요. 정리하시느라 고생 많으셨어요 ㅠㅠ 감사합니다!! 의견 보시고 피드백 부탁드려요~~

[juyohan]

최종 초기 DB 스키마

테이블

• users (유저 정보)

user_nickname : 드래프트 내에서 사용할 이름 kakao_code : 카카오에서 받은 토큰 받기 요청에 필요한 인가 코드..? (이 부분은 로그인 구현을 통해 정확히 확인 할 필요가 있음.) kakao_image_path : 카카오 프로필 사진의 url 정보 kakao_email : 카카오에서 받은 이메일 정보

• players (선수 정보)

player_name : 선수의 이름 player_position : 선수의 포지션 player_three : 3점 성공률 player_fg : 슛 성공률 player_ft : 자유투 성공률 player_pts : 총 득점 player_reb : 리바운드 개수 player_ast : 어시스트 개수 player_st : 스틸 개수 player_blk : 블락 개수 player_to : 턴오버 개수 player_td : 트리플 더블 개수 player_team : 팀 이름 player_status : 선수의 상태

• bid_logs (입찰의 모든 로그)

bid_amount : 입찰 가격

• player_acquisitions (선수 인수)

acquisition_amount : 인수 가격 selected_num : 선택된 순서 user_budget : 사용자의 현재 남은 금액

• auctions (드래프트룸 정보)

auction_name : 현재 드래프트 방의 이름 (과거 드래프트의 결과 값을 유지하기 위해)

연관관계

• users(1) ←→ bid_logs(N)

  한명의 사용자는 여러번의 입찰을 진행 할 수 있음.

• bid_logs(N) ←→ players(1)

  한명의 선수는 여러번의 입찰이 될 수 있음.

• bid_logs(1) ←→ player_acquisitions(1)

  많은 입찰 정보들 중에서 하나의 입찰 정보가 최종 인수가 됨.

• player_acquisitions(N) ←→ auctions(1)

  하나의 드래프트 내에선 여러개의 인수정보가 있음.

[juyohan]

bid_logs와 player_acquisitions 의 연관관계 수정 (N:1)

[juyohan]

• 사용자가 소지하고 있는 금액을 관리하기 위해 user_states의 테이블을 생성한 뒤, auction과 user 간 N:M의 연관관계 추가.
• players 테이블에 column명 변경 (약어를 풀네임으로) 및 다른 테이블의 column 명 변경

[philipjkim]

@juyohan 개인적으로 user_states 테이블 명이 바뀌어야 한다고 생각합니다. 그 이유는 아래와 같습니다:

• user 는 auction 과는 전혀 관계가 없는 로그인한 사용자의 정보임
• user_states 에 들어가는 auction_id, budget 은 auction 에 의존성이 있음
• user 가 어떤 auction 에 참여하는 경우는 user 가 아닌 다른 이름을 가져야 함 (bidder 추천, 입찰자라는 뜻이 맞으므로)
• 따라서, user_states -> bidders 로 변경하고 Bidder 라는 JPA entity 를 정의해서 사용하면 됨

[juyohan]

@juyohan 개인적으로 user_states 테이블 명이 바뀌어야 한다고 생각합니다. 그 이유는 아래와 같습니다:

• user 는 auction 과는 전혀 관계가 없는 로그인한 사용자의 정보임
• user_states 에 들어가는 auction_id, budget 은 auction 에 의존성이 있음
• user 가 어떤 auction 에 참여하는 경우는 user 가 아닌 다른 이름을 가져야 함 (bidder 추천, 입찰자라는 뜻이 맞으므로)
• 따라서, user_states -> bidders 로 변경하고 Bidder 라는 JPA entity 를 정의해서 사용하면 됨

안그래도 테이블 명에 대해서 고민을 했었는데, 사용자의 budget 을 가지고 있으니 user_states 라고 작명을 지었습니다. 확실히 한 auction에서 user 들은 입찰자가 되어 입장하니, bidders 이라는 이름이 더 올바른 이름이네요. 작명.. 너무 어렵네요ㅠㅠ

[juyohan]

@kimdg1105 @philipjkim

• user_states → bidders 로 이름 변경
• users 안에 있는 nickname 을 bidders 로 이동 (각 드래프트마다 사용되는 이름은 바뀔 수 있기 때문에, auction에 의존성을 둔 bidders에 두는게 좋은 것 같습니다.)

[kimdg1105]

@juyohan 테이블명 변경 확인했습니다. Users 안에 있는 닉네임의 경우 드래프트마다 사용자 닉네임이 변경된다면 해당 테이블 row를 업데이트 하는 방향으로 생각하고 있었는데, bidders 쪽으로 들어가면 과거 닉네임 내역까지도 볼 수 있겠네요 좋은거 같아요!

[juyohan]

초기 DB에 대한 기반은 어느정도 잡혔으니 해당 이슈는 닫고, 추후 DB에 변경부분이 있다면 새로운 이슈를 작성 및 재오픈해서 하는거로 하겠습니다.