CH 3 풋살 온라인 프로젝트 - 트러블 슈팅 0913

 

🎒 인벤토리란 무엇인가

jwt 토큰 인증 이슈로 인해 이전 개인과제에서 인벤토리 구현을 해보지 못했기 때문에, 실제로 데이터베이스에 어떻게 데이터가 쌓이는지 감이 오지 않았다. 당연히 가방처럼 플레이어당 하나의 인벤토리가 생성되고, 그 안에 아이템의 id와 갯수(count)가 쌓인다고 생각했다. 그러나 팀원들과 이야기를 나누다보니, 인벤토리의 슬롯 하나로 이해하는 경우도 있었다. 그러면 DB가 너무 더러워져서 관리하기 어렵지 않은가? 로그처럼 데이터를 계속 누적하는 건데... 아이템을 사고 팔거나 장착할 때 꼬이지 않는 것인가? 라는 의문이 들었지만... 사실 해당 기능을 제대로 구현했던 적이 있는 사람은 없었기에 다같이 공부한 뒤 다시 모여야 했다.

 

해설 영상을 참고해보니, 하나의 아이템이 인벤토리에 들어올 때마다 DB에 한줄씩 생기는 구조였다.

 

▼ 예시

Inventory
id	user_id	item_code	count
1	1	2	1
2	1	5	1
3	1	2	1
4	2	1	1
5	2	4	1

 

1번 유저가 소지한 아이템을 확인하고 싶으면, router에서 함수를 통해 user_id가 1인 경우를 모두 불러온 뒤 item code가 일치하면 count가 올라가는 식으로 구현되어 있었다. 물론 다른 방식으로 인벤토리를 구성할 수도 있으나, 현재 입문 단계인 우리의 수준에서 응용하려면 해설 영상과 동일한 방식으로 도전해보는 것이 좋을 것 같다고 판단되었다. 

 

피파에서 선수 카드를 뽑는 것처럼, 풋살온라인에서도 선수 카드를 뽑아야 하기 때문에 인벤토리는 핵심 기능 중 하나가 될 것 같다. 이번에는 꼭 멋지게 구현할 수 있기를!

 

 

🏷️ 나에겐 너무 많은 id

개인과제를 만들 때, 각 테이블마다 부여되는 primary key인 id 값을 혼동하지 않기 위해 열심히 테이블 명을 앞에 붙여주었다. Users 테이블에는 user_id, Character 테이블에는 character_id.... 여기저기 서로 참조하는 데이터들이 많으니, 깔끔하게 관리하려면 다 구분할 수 있게 이름을 설정하는 게 맞는 것이라고 생각했다.

 

그러나 오늘 튜터님에게 피드백을 받아보니, 그럴 필요가 없었다. 각 테이블에 primary key는 그저 id로 공통적으로 선언해주고, 불러올 때(참조할 때) 별도의 네이밍을 해주면 되는 것이었다.

 

▼ 기존에 작업했던 방식

 

▼ 튜터님 피드백을 반영한 방식

relation에서 references가 참조하는 컬럼인지, 현재 테이블의 컬럼인지 헷갈렸다. 틀리지 않았기를 바라며 복습을..

 

튜터님의 피드백을 받은 만큼 이번에는 더 깔끔하고 체계적인 DB를 만들고, 관리할 수 있기를 바란다.

 

 

 

---

 

데이터베이스를 프론트에서나 많이 다뤄봤지, 백엔드에서 다뤄보려니 고려할 부분이 많이 달라서 새롭다. Oracle의 Eloqua를 통해 신규 DB를 설계하는 과정에 참여했을 때, 마케터 입장에서 저장할 고객정보를 어떻게 묶고 어떤 형식으로 받아서 관리할지 정리하다보면 개발자분들의 표정이 조금씩 변하고는 했다. RDB라는 것이 이렇게 고려할 부분이 많다는 것을 그때 조금 더 알았다면... 더 좋은 DB 구조를 만들 수 있었을까?