DB Modeling

CoinAlarm의 DB 설계

• 사용자(User): 회원 한 명
• 코인(Coin): 비트코인, 이더리움 등
• 코인가격(Price): 현재가가 아니라, 사용자가 목표로 지정한 가격
• 알림(Alert): “이 코인이 이 가격 도달하면 알려줘!”

그래서 모델링 개념으로 풀어보면

한 사용자가 여러 코인에 대해 여러 목표가를 설정할 수 있음

예:

• 철수는 비트코인 5천만원, 6천만원
• 영희는 이더리움 400만원

즉,

사용자 1:N 알림
코인 1:N 알림

→ 결국 핵심은 “알림” 테이블이 사용자, 코인, 목표가격을 다 들고 있어야 함

추천 설계 (깔끔하고 직관적인 버전)

1. User 테이블

2. Coin 테이블

3. PriceAlert (or Alert) 테이블 – 핵심

장점

• 구조가 단순함 (JOIN 쉬움)
• 하나의 알림 = 하나의 사용자 + 하나의 코인 + 하나의 가격
• 확장성 좋음 (예: alert_type 컬럼으로 “목표가”, “변동률”, “일일 알림” 등 추가 가능)

그럼 너가 말한 구조는?

“코인-사용자-코인가격” 테이블
이게 사실상 내가 위에 쓴 PriceAlert임

“코인-코인가격 테이블 + 사용자–코인-코인가격 테이블”
이건 목표 가격을 공통 리소스로 보고 여러 사람이 같이 참조하는 구조인데,
→ 사실상 그럴 일이 없음
→ 왜냐면, 목표가는 개인마다 다르고 고유한 정보니까

결론

가장 깔끔한 설계는:

[User] ---< [PriceAlert] >--- [Coin]

PriceAlert 안에 목표 가격, 생성 시간, 타입 등이 들어 있음.

원하면 이 구조로 실제 SQL DDL 만들어줄 수도 있고,
목표가 외에 “일일 알림”, “변동률 알림” 같이 확장 가능한 구조도 같이 설계해줄게!
더 고도화하고 싶으면 예: 알림 기록 로그까지 고려해볼 수도 있고.

같은 가격을 여러 사람이 설정할 수도 있잔아? 굳이 고려할 필요는 없나?

맞아, 같은 가격을 여러 사람이 설정할 수도 있어. 예를 들어:

• 철수: 비트코인 5천만원 알림
• 영희: 비트코인 5천만원 알림

→ 그럼 5천만 원이라는 목표가를 따로 테이블로 빼는 게 맞을까?

생각해볼 수 있는 구조

1. TargetPrice 테이블

   • price_id (PK), price (e.g. 50000000)

2. Alert 테이블

   • user_id, coin_id, price_id (FK)

이렇게 하면 중복된 가격을 여러 사람이 공유하게 되는 거지.

그런데 이 구조는 현실에서 딱히 이득이 없음

그래서 정답은:

그냥 Alert 테이블에 target_price 숫자값으로 넣는 게 제일 낫다.

CREATE TABLE Alert (
    alert_id BIGINT AUTO_INCREMENT PRIMARY KEY,
    user_id BIGINT NOT NULL,
    coin_id BIGINT NOT NULL,
    target_price DECIMAL(20, 2) NOT NULL,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    notified BOOLEAN DEFAULT FALSE,
    FOREIGN KEY (user_id) REFERENCES User(user_id),
    FOREIGN KEY (coin_id) REFERENCES Coin(coin_id)
);

요약

• 같은 가격을 여러 사람이 설정할 수는 있지만, 그건 그 사람만의 알림이므로,
  공유할 가치가 없음
• 중복 숫자 저장해도 문제 없고, 그게 자연스러운 구조임
• 그래서 target_price는 Alert 테이블 안에 직접 넣는 걸 추천!

원하면 알림 타입 구분 (목표가, 변동률, 일일) 도 같이 설계해줄게!
어떻게 확장할지도 궁금해?

📌 그래서 모델링 개념으로 풀어보면

🎯 한 사용자가 여러 코인에 대해 여러 목표가를 설정할 수 있음

예:

• 철수는 비트코인 5천만원, 6천만원
• 영희는 이더리움 400만원

즉,

사용자 1:N 알림
코인 1:N 알림

→ 결국 핵심은 “알림” 테이블이 사용자, 코인, 목표가격을 다 들고 있어야 함

✅ 추천 설계 (깔끔하고 직관적인 버전)

1. User 테이블

2. Coin 테이블

3. PriceAlert (or Alert) 테이블 – 핵심

✨ 장점

• 구조가 단순함 (JOIN 쉬움)
• 하나의 알림 = 하나의 사용자 + 하나의 코인 + 하나의 가격
• 확장성 좋음 (예: alert_type 컬럼으로 “목표가”, “변동률”, “일일 알림” 등 추가 가능)

🤔 그럼 너가 말한 구조는?

“코인-사용자-코인가격” 테이블
이게 사실상 내가 위에 쓴 PriceAlert임

“코인-코인가격 테이블 + 사용자–코인-코인가격 테이블”
이건 목표 가격을 공통 리소스로 보고 여러 사람이 같이 참조하는 구조인데,
→ 사실상 그럴 일이 없음
→ 왜냐면, 목표가는 개인마다 다르고 고유한 정보니까

✅ 결론

가장 깔끔한 설계는:

[User] ---< [PriceAlert] >--- [Coin]

PriceAlert 안에 목표 가격, 생성 시간, 타입 등이 들어 있음.

원하면 이 구조로 실제 SQL DDL 만들어줄 수도 있고,
목표가 외에 “일일 알림”, “변동률 알림” 같이 확장 가능한 구조도 같이 설계해줄게!
더 고도화하고 싶으면 예: 알림 기록 로그까지 고려해볼 수도 있고.

같은 가격을 여러 사람이 설정할 수도 있잔아? 굳이 고려할 필요는 없나?

맞아, 같은 가격을 여러 사람이 설정할 수도 있어. 예를 들어:

• 철수: 비트코인 5천만원 알림
• 영희: 비트코인 5천만원 알림

→ 그럼 5천만 원이라는 목표가를 따로 테이블로 빼는 게 맞을까?

🤔 생각해볼 수 있는 구조

1. TargetPrice 테이블

   • price_id (PK), price (e.g. 50000000)

2. Alert 테이블

   • user_id, coin_id, price_id (FK)

이렇게 하면 중복된 가격을 여러 사람이 공유하게 되는 거지.

✅ 그런데 이 구조는 현실에서 딱히 이득이 없음

✅ 그래서 정답은:

그냥 Alert 테이블에 target_price 숫자값으로 넣는 게 제일 낫다.

CREATE TABLE Alert (
    alert_id BIGINT AUTO_INCREMENT PRIMARY KEY,
    user_id BIGINT NOT NULL,
    coin_id BIGINT NOT NULL,
    target_price DECIMAL(20, 2) NOT NULL,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    notified BOOLEAN DEFAULT FALSE,
    FOREIGN KEY (user_id) REFERENCES User(user_id),
    FOREIGN KEY (coin_id) REFERENCES Coin(coin_id)
);

🙋 요약

• 같은 가격을 여러 사람이 설정할 수는 있지만, 그건 그 사람만의 알림이므로,
  공유할 가치가 없음
• 중복 숫자 저장해도 문제 없고, 그게 자연스러운 구조임
• 그래서 target_price는 Alert 테이블 안에 직접 넣는 걸 추천!