내일배움캠프 5주차 월요일 TIL

쿠키?
브라우저가 서버로부터 받은 정보를 클라이언트측에 저장하는 방식
내가 브라우저 방문 시 쿠키를 저장한 후, 이후 방문 때 마다 브라우저는 해당 쿠키도 요청과 함께 서버로 보낸다.
서버가 정한 기간에 따라 유효기간 존재한다
인증뿐만 아니라 다양한 정보를 담을 수 있다.


세션?
서버에서 관리되는 사용자 정보를 저장하는 방식.
사용자가 로그인할 때 세션 ID가 생성되고, 이 ID를 통해 사용자를 식별한다.
세션은 서버의 세션 DB에 모든 정보를 저장해야 하므로, 사용자 수가 많아질수록 데이터베이스의 부담이 커진다.

서버로 가는 모든 요청은 이전 요청과 독립적으로 처리된다.
요청이 끝나면 서버는 사용자의 정보를 잊어버린다. > 매 요청 시마다 사용자가 누구인지 서버에 알려줘야 한다.

세션을 통한 사용자 인증 과정:
사용자가 유저명과 비밀번호를 서버에 전송한다.
서버는 비밀번호가 맞는지 확인한다.
비밀번호가 맞다면, 서버는 세션 데이터베이스에 세션 ID를 생성한다.
생성된 세션 ID는 쿠키를 통해 브라우저로 전송된다.
브라우저는 이 쿠키를 저장한다.
사용자가 같은 웹사이트의 다른 페이지로 이동할 때, 브라우저는 자동으로 세션 ID가 포함된 쿠키를 서버에 전송한다.
서버는 요청과 함께 오는 쿠키에서 세션 ID를 확인한다.
서버는 세션 ID를 사용하여 세션 데이터베이스를 조회하고, 사용자가 누구인지 인식하게 된다.

중요한 유저정보는 모두 서버에 잇고, 유저는 세션 id만 가지고 있다 > 쿠키는 세션아이디를 전달하기 위한 매개체일뿐

세션으로 ios 안드로이드 앱을 만들 수 있으나 쿠키는 x (브라우저에만 있기 때문에)
>> 이럴 때 토큰 사용 서버에 토큰을 보내는 방식


jwt > 토큰 형식 > 이상하게 생긴 스트링
jwt로 유저 인증을  처리하면 세션 db를 가질 필요가 없고 서버는 인증한다고 많은  을 하지 않아도 된다

세션에선 그냥 세션아이디만 주면 됨
요청하면 서버는 세션id를db에서 찾기만한다
jwt에선 서버는 유저를 인증하는데 필요한 정보를 토큰에 저장 , 저장 후 브라우저에 보냄
이후 요청을 받으면 서버는 해당 토큰이 유효한지만 검증 >> db를 거칠 필요가 없다
jwt는 암호화 되지 않음 > 누구나 확인 가능 > 비밀정보를 jwt에 두면 안됨

세션
1. 세션 사용 시 서버는 로그인된 유저의 모든 정보를 저장, 세션db를 사고 유지해야함 이는 유저가 많아질 수 록 커지겠지
대신 정보를 바탕으로 많은 것을 할 수 있다.
ex) 세션을 삭제하여 강제 로그아웃 

jwt 사용 시 생성된 토큰이 유효한가 아닌가만 서버가 판단, db 필요없음




프리즈마 스키마 작성
프리즈마를 사용하면 위와 같은 SQL문을 직접 작성할 필요 없이, 프리즈마 스키마 파일에 모델을 정의하고 마이그레이션을 통해 테이블을 생성할 수 있다

1:1 관계 (One-to-One)
한 개체가 다른 개체와 1:1로 연결
예시: 각 사람은 하나의 주민등록증을 가질 수 있으며, 각 주민등록증은 하나의 사람에게만 속합니다.
구현 방법: 두 테이블 모두에서 서로의 기본 키를 외래 키로 사용하여 관계를 설정합니다.

1:N 관계 (One-to-Many)
한 개체가 여러 개체와 연결
예시: 한 고객이 여러 주문을 할 수 있지만, 각 주문은 하나의 고객에게만 속합니다.
구현 방법: 외래 키를 사용하여 다수의 행이 하나의 행에 연결되도록 설정합니다.

N:1 관계 (Many-to-One)
여러 개체가 한 개체와 연결
예시: 여러 학생이 하나의 수업에 등록될 수 있습니다.
구현 방법: 외래 키를 사용하여 여러 행이 하나의 행에 연결되도록 설정합니다.

N:M 관계 (Many-to-Many)
여러 개체가 여러 개체와 연결
예시: 학생과 수업의 관계에서, 한 학생이 여러 수업을 수강할 수 있고, 한 수업에 여러 학생이 등록될 수 있습니다.
구현 방법: 중간 테이블(조인 테이블)을 생성하여 두 개체 간의 관계를 관리합니다. 예를 들어, Student_Class라는 테이블을 만들어 student_id와 class_id를 외래 키로 설정할 수 있습니다.


아이템 시뮬레이션 테이블 API
아이템 테이블 (Items)
컬럼:
item_id: 아이템 고유 ID (Primary Key)
name: 아이템 이름
type: 아이템 종류 (예: 무기, 방어구 등)
attributes: 아이템 속성 (예: 공격력, 방어력 등)
created_at: 생성일시
관계: 아이템은 캐릭터-인벤토리 테이블과 캐릭터-아이템 테이블에 연결됩니다.

계정 테이블 (Accounts)
컬럼:
account_id: 계정 고유 ID (Primary Key)
username: 사용자 이름
password: 비밀번호 (해시 처리)
created_at: 생성일시
관계: 하나의 계정은 여러 개의 캐릭터를 가질 수 있습니다. (1:N 관계)

캐릭터 테이블 (Characters)
컬럼:
character_id: 캐릭터 고유 ID (Primary Key)
account_id: 계정 ID (Foreign Key)
name: 캐릭터 이름
level: 캐릭터 레벨
created_at: 생성일시
관계: 캐릭터는 여러 개의 아이템을 가질 수 있으며, 캐릭터-인벤토리 테이블과 캐릭터-아이템 테이블에 연결됩니다.

캐릭터-인벤토리 테이블 (Character_Inventory)
컬럼:
inventory_id: 인벤토리 고유 ID (Primary Key)
character_id: 캐릭터 ID (Foreign Key)
item_id: 아이템 ID (Foreign Key)
quantity: 보유 수량
관계: 캐릭터가 보유하고 있지만 장착하지 않은 아이템 정보를 저장합니다. (N:M 관계)

캐릭터-아이템 테이블 (Character_Items)
컬럼:
character_item_id: 고유 ID (Primary Key)
character_id: 캐릭터 ID (Foreign Key)
item_id: 아이템 ID (Foreign Key)
equipped: 장착 여부 (Boolean)
관계: 캐릭터가 실제로 장착한 아이템 정보를 저장합니다. (N:M 관계)


요구사항 정리

아이템 생성 API
아이템 정보를 입력받아 아이템 테이블에 새로운 아이템을 생성합니다.
생성된 아이템의 ID는 다른 테이블에서 참조할 수 있도록 반환해야 합니다.

계정 관리
계정 생성, 로그인, 로그아웃 기능을 제공해야 합니다.
각 계정은 여러 캐릭터를 생성할 수 있어야 합니다.

캐릭터 관리
캐릭터 생성, 삭제, 수정 기능을 제공해야 합니다.
각 캐릭터는 특정 계정에 속해야 하며, 레벨과 같은 속성을 가집니다.

인벤토리 관리
캐릭터가 보유한 아이템을 인벤토리에 추가하거나 제거할 수 있어야 합니다.
인벤토리에서 아이템의 수량을 관리해야 합니다.

장착 아이템 관리
캐릭터가 장착한 아이템을 관리할 수 있어야 합니다.
장착 및 해제 기능을 제공하여 캐릭터의 장착 상태를 업데이트해야 합니다.


프리즈마 스키마 작성 후 
npx prisma db push 명령어를 통해 테이블 생성

데이터베이스 item-db와 연결하였고, 테이블이 정상적으로 생성되었다.

여기까지의 작업을 프리즈마 스키마 작성(프리티어 추가), add로 깃허브 리포지토리에 커밋하였다

오늘 진행한 작업
1. 프리즈마 스키마 작성
위 정리한 테이블, 테이블 간 관계를 참고하여 작성하였다.
각 테이블의 컬럼, 컬럼의 타입, 제약조건 추가 등을 적용하였다

2. 데이터베이스 연결 및 테이블 생성
EC2 를 통해 인스턴스, RDS를 통해 item-db라는 데이터베이스 생성 후 EC2와 RDS를 연동하였고,
npx prisma db push 명령어를 사용하여 정의한 스키마에 따라 테이블을 생성하였다.

3. GitHub 리포지토리에 커밋
작성한 프리즈마 스키마와 관련된 변경 사항을 add를 통해 GitHub 리포지토리에 커밋하였다

4. 테이블 확인
SHOW TABLES, DESCRIBE Accounts; 명령어를 new query에 작성하여 테이블이 잘 생성되었는지 확인하였다.

5. API 개발
회원가입 API, 캐릭터 생성 API를 이전 강의의 게시판 실습을 참고하여 작성 중이고 추가 작업 필요,
추가적으로 어떤 API가 필요한지 고민이 필요하다.