개인 프로젝트 DB 설계중.

구조 설계의 핵심.

• 구체화된 검색기능 제공을 위한 테이블 분리를 생각하며 만들어보자
• 판매권한 레벨을 userId에 부여하자
• 일단 해보고 이상하면 수정하자.

만들던 중 고민

악기도 악기 속성별로 나누어야할지 아니면 다 instrument에 넣을지 고민이다.

그래서 사이트 참고 결과 말이 악기지 악기의 사운드들을 특정적으로 배치하는 모습이 보인다.

일단은 그냥 이 형식을 따라보자.

• 테이블 분리하기로 결정.

일단 설계는 여기까지 했다. 더 필요한게 무엇일까.

내 머리로는 뭐가 더 필요할지 더 나오지가 않아서 GPT한테 계획서랑 함께 뭐가 혹시 더 필요한지 물어보았다.

1. Spotify API를 통한 회원가입 및 로그인
OAuth 통합: Spotify API를 통해 회원가입 및 로그인을 구현하려면 OAuth 2.0을 활용한 인증이 필요합니다. 이 과정에서 사용자의 고유 ID, 이메일, 프로필 사진 등을 DB에 저장할 필요가 있습니다. 이를 위해 users 테이블에 Spotify 사용자 ID 및 관련 필드를 추가해야 합니다.
중복 가입 방지: Spotify ID를 기준으로 중복 가입을 방지할 수 있는 로직이 필요합니다. 기존 loginId 대신 Spotify ID를 loginId로 사용하거나 별도의 spotify_id 필드를 추가할 수 있습니다.
DB 보완:

spotify_id (VARCHAR): Spotify에서 제공하는 고유 사용자 ID를 저장.

2. Toss Payments를 활용한 결제 시스템
결제 내역 저장: 사용자가 결제를 통해 코인을 구입한 내역을 기록해야 합니다. 현재 설계된 coin_transactions 테이블이 적절하게 활용될 수 있지만, 결제와 관련된 추가 필드(예: 결제 ID, 결제 상태, 결제 방법 등)를 추가하는 것이 좋습니다.
결제 처리 결과: Toss Payments API에서 제공하는 결제 결과를 저장할 수 있는 필드가 필요합니다. 이는 결제 실패, 성공 여부를 추적하고, 필요시 결제 상태를 업데이트할 수 있도록 돕습니다.
DB 보완:

payment_id (VARCHAR): Toss Payments에서 제공하는 고유 결제 ID.
payment_status (ENUM): 결제 상태 (예: 'pending', 'completed', 'failed').
payment_method (ENUM): 결제 방법 (예: 'credit_card', 'kakao_pay').

3. 웹상 재화 전환 (사이트 내 저장소)
저장소 설계: 사용자가 결제를 통해 얻은 코인을 보관할 "저장소"는 현재의 coins 테이블로 충분합니다. 다만, 각 사용자가 구매한 음원이나 샘플을 관리할 수 있는 구조가 필요할 수 있습니다.
구매한 아이템 관리: purchased_items 테이블을 추가하여 사용자가 구매한 샘플이나 트랙을 관리할 수 있습니다.
DB 보완:

purchased_items 테이블:
id (Primary Key, INT)
user_id (Foreign Key, INT)
sample_id (Foreign Key, INT)
purchase_date (DATETIME)

4. 음원 업로드 및 다운로드 시스템
파일 저장소: 업로드된 음원 파일의 경로, 메타데이터 등을 관리할 수 있는 테이블이 필요합니다. 이를 통해 사용자는 업로드된 음원을 다운로드하거나 미리 듣기를 할 수 있습니다.
미리 듣기 설정: 음원 파일의 경로 및 미리 듣기 파일의 경로를 저장할 수 있는 필드가 필요합니다.
DB 보완:

uploaded_files 테이블:
id (Primary Key, INT)
user_id (Foreign Key, INT)
file_path (VARCHAR): 파일이 저장된 경로.
preview_path (VARCHAR): 미리 듣기 파일 경로.
upload_date (DATETIME)

5. 샘플 검색 및 업로드 시 메타데이터 관리
메타데이터 관리: 샘플 업로드 시 추가되는 메타데이터를 저장할 수 있는 구조가 필요합니다. 예를 들어, 장르, BPM, 키워드 등을 저장할 수 있어야 합니다. 이러한 정보는 검색 기능에서 중요한 역할을 합니다.
검색 기능: 검색 기능의 성능을 위해 인덱싱이 잘 되어야 하며, 필요한 경우 full-text search 기능을 사용하거나, Elasticsearch와 같은 전문 검색 엔진을 활용할 수 있습니다.
DB 보완:

sample_metadata 테이블:
id (Primary Key, INT)
sample_id (Foreign Key, INT)
genre (VARCHAR)
bpm (INT)
keywords (VARCHAR): 쉼표로 구분된 키워드 목록.

6. 사용자 권한 레벨 및 심사 시스템
권한 레벨 관리: 사용자의 권한을 세분화하고, 판매 가능 여부를 설정하는 기능은 이미 설계된 authLevel 필드에서 충분히 처리할 수 있습니다. 추가로 심사 시스템을 구현할 계획이라면, 심사 요청과 결과를 관리할 수 있는 테이블이 필요합니다.
심사 요청 관리: 사용자가 판매자로 전환하기 위한 심사 요청을 관리하는 테이블이 필요합니다.
DB 보완:

review_requests 테이블:
id (Primary Key, INT)
user_id (Foreign Key, INT)
request_date (DATETIME)
status (ENUM): 심사 상태 (예: 'pending', 'approved', 'rejected').
review_date (DATETIME)
reviewer_id (Foreign Key, INT): 심사를 담당한 관리자 ID.

7. Spotify API와 연동된 기능
Artist 판별 및 관리: Spotify API를 통해 사용자가 아티스트인지 여부를 확인하는 기능이 필요합니다. 아티스트 정보를 저장할 수 있는 필드를 추가하고, 아티스트 관련 기능(예: 트랙 업로드)을 관리할 수 있어야 합니다.
DB 보완:

spotify_artist_id (VARCHAR): Spotify에서 제공하는 아티스트 ID.

아.. 뭐가 이렇게 많냐고..

일단 이걸 살펴보고 진짜 필요한지 아닌지 검토해보자. spotify API를 사용할거니까 해당 아이디를 저장할 곳은 필요한게 맞는 것 같다, Toss Payments api도 마찬가지. 사용자가 구매한 샘플을 저장할 테이블도 필요할 것 같다.
음원 업로드 및 다운로드 시스템은 추가할거니까 당연히 필요할테고, 사용자 권한 레벨 및 심사 시스템을 하려면 평가에 대한 데이터가 필요할테니까 또 필요하고.. 마지막껀 실현불가능이라 폐지니까, 그냥 하나 빼고 다 필요한데?

아 이건 그냥 지금 해놓는게 나을까 잘 모르겠다. 일단 여기 메모는 해뒀으니까 고민을 좀 해보자.

우선 최종 DB 설계는 저 위의 것이고 나머지는 뭔가 만들다가 필요할 때 추가하는 식으로 하는게 좋을 것 같다.