먼저 질문부터!
“나는 스포츠 경기에서 어떤 정보를 관리하려고 하는 걸까?”
이 질문이 바로 DB 목적을 명확히 하는 출발점이다.
예시 1: 경기 결과를 저장하려는 경우
DB 목적: “각 팀의 경기 결과(승/패/무, 점수 등)를 저장하고 분석한다.”
테이블 설계 방향 예:
- Match (경기 일시, 장소)
- Team (팀 이름, 리그 정보 등)
- Match_Result (팀별 점수, 승/패 여부)
→ 이 DB는 경기 결과 통계용이다. 예를 들어:
“2025년 4월 10일, 서울 팀 vs 부산 팀, 점수는 3:2, 승자는 서울 팀”
예시 2: 선수별 기록을 저장하려는 경우
DB 목적: “선수 개인의 경기 내 활동(득점, 어시스트, 반칙 등)을 기록한다.”
테이블 설계 방향 예:
- Player (선수 이름, 포지션, 소속팀)
- Match (경기 정보)
- Player_Stats (경기당 득점, 패스, 반칙 등)
→ 이 DB는 개인 성적 관리용이다.
“김철수 선수, 2025년 4월 10일 경기에서 2골, 1어시스트”
예시 3: 리그 순위 관리를 위한 DB
DB 목적: “한 시즌 동안 팀들의 순위를 계산한다.”
테이블 설계 방향 예:
- League (시즌 정보)
- Team
- Team_Standing (승/무/패, 승점, 순위)
→ 이건 시즌 통계 / 리그 순위 집계용 DB이다.
“서울 팀은 10승 2무 3패, 승점 32점으로 1위”
✅ 결론: 목적이 다르면 DB도 다르다!
| 목적 | 주요 테이블 | 설명 |
| 경기 결과 저장 | Match, Match_Result | 누가 이겼는지를 기록 |
| 선수 통계 관리 | Player, Player_Stats | 개인 퍼포먼스 저장 |
| 리그 순위 계산 | Team, Team_Standing | 시즌 누적 승점 계산 |
똑같은 “스포츠 경기”를 다뤄도, DB의 목적이 다르면 테이블 구조도 전혀 달라짐.
💬 한마디 요약
“DB의 목적을 명확히 한다“는 건
“내가 이 DB로 뭘 알고 싶은지, 뭘 관리하고 싶은지 정확히 결정하고 나서 설계하라는 뜻임.”
이번에는 “목적이 불명확한 DB의 예”와 그로 인한 문제점은 무엇일까?
현업에서도 이런 DB 구조를 많이 만나게 되고, 결국은 유지보수 지옥🔥이 되기 쉽습니다.
📌 목적이 불명확한 DB의 예
⚠️ 예시: 스포츠 경기 DB인데… 전부 한 테이블에?
TABLE GAME_INFO (
TEAM_NAME,
PLAYER_NAME,
SCORE,
POSITION,
GAME_DATE,
WIN_YN,
LEAGUE_NAME,
COACH_NAME,
TEAM_RANK,
PLAYER_HEIGHT,
STADIUM_NAME
)
❌ 이게 왜 문제냐면?
1. 무슨 목적의 DB인지 알 수 없음
- 이 테이블은 경기 결과를 저장하려는 건지,팀 통계를 관리하려는 건지 모호함
- 선수 정보를 저장하려는 건지,
👉 설계자가 아닌 이상 “이 컬럼은 뭘 위한 걸까?” 계속 헷갈림
2. 단일 책임 원칙 위배
- 한 테이블에 선수 정보, 팀 정보, 경기 결과, 경기장 정보가 다 섞여 있음
- 즉, 이 테이블은 한 가지 목적이 아니라 여러 목적이 섞인 “잡탕 구조”
👉 수정할 때마다 여러 책임이 얽혀 있어 버그 발생 가능성 UP
3. 데이터 중복 및 무결성 문제
- 팀 이름이 매 경기마다 반복 저장됨 → 중복
- 선수 키(PLAYER_HEIGHT)가 경기마다 다를 수 있음 → 모순
- 코치 이름 바꾸려면 여러 행 다 수정해야 함 → 유지보수 지옥
4. 질문에 답하기 어려움
- 예: “김철수 선수의 시즌 총 골 수는?”
- → 정규화 안 된 구조에선 골 찾기도 어렵고, 신뢰도도 낮음
✅ 같은 사례, 목적이 명확한 구조로 바꾸면?
| 목적 | 테이블 |
| 선수 관리 | PLAYER (player_id, name, height, position, team_id) |
| 팀 정보 | TEAM (team_id, team_name, coach_name) |
| 경기 정보 | MATCH (match_id, date, stadium, home_team_id, away_team_id) |
| 기록 | PLAYER_STATS (match_id, player_id, score, assist, foul) |
👉 이제는 “목적별 테이블이 명확히 분리”되어 있어서 수정도 쉽고, 통계도 정확하게 낼 수 있음.
🔚 요약
| 항목 | 불명확한 DB | 명확한 DB |
| 목적 | 여러 기능이 뒤섞임 | 하나의 목적에 맞는 테이블 |
| 구조 | 중복되고 모순될 수 있음 | 정규화로 일관된 구조 |
| 유지보수 | 어렵고 위험함 | 유연하고 안정적 |
| 쿼리 | 비효율적이고 모호함 | 명확하고 빠름 |
💬 한마디 정리
DB 목적이 불명확하면:
- 테이블은 비대해지고
- 데이터는 중복되고
- 유지보수는 고통이 되고
- 아무도 그 DB를 쓰고 싶어 하지 않게 됨. 😥