인프런 커뮤니티 질문&답변

작성한 질문수

5천억건이 넘는 금융 데이터를 처리하는 토스 개발자에게 배우는 MySQL

테이블 및 데이터 모델링 해보기

칼럼명

해결된 질문

작성

-- 유저 테이블
CREATE TABLE Users (
   user_id INT AUTO_INCREMENT PRIMARY KEY,
   username VARCHAR(50) NOT NULL,
   email VARCHAR(100) NOT NULL,
   created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
   UNIQUE KEY uq_username (username), -- 유저명은 유일해야 함 (대체키)
   UNIQUE KEY uq_email (email)         -- 이메일은 유일해야 함 (대체키)
);

-- 태그 테이블
CREATE TABLE Tags (
  tag_id INT AUTO_INCREMENT PRIMARY KEY,
  name VARCHAR(50) NOT NULL,
  UNIQUE KEY uq_name (name)
);


-- 게시글 테이블
CREATE TABLE Posts (
       post_id INT AUTO_INCREMENT PRIMARY KEY,
       user_id INT NOT NULL,
       title VARCHAR(200) NOT NULL,
       content TEXT NOT NULL,
       created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
       KEY idx_user_id (user_id), -- 작성자별 게시글 조회를 위해 인덱스 추가
       FOREIGN KEY (user_id) REFERENCES Users(user_id)
);

위처럼 하셨는데

자기참조를 할 경우도 있어서

저는 primary key 는 id 로 두고있거든요

혹시 user 테이블에 user_id 컬럼명으로 하신 이유가 있나요 ?

mysql jetbrains mysql-query

답변 2

Hong

지식공유자

안녕하세요 SJ님 질문 주셔서 감사합니다. 새해 복 많이 받으세요 ㅎㅎ

일단 무엇이 틀렸다 맞다라는 논쟁은 아닌거 같고 개인적인 취향과 가독성 측면에서 차이가 있을거같습니다.

저는 어느정도 JOIN을 하는데에 있어서 의미가 더 명확한거 같아서 다음과 같이 수행한 바도 있어요. 예를들어서

SELECT *
FROM Posts p
JOIN Users u ON p.user_id = u.user_id;

이런 쿼리만 봐도 어떤 테이블의 키인지 명확하고 다중 조인하는 상황이 발생해도 가독성이 좋다고 생각합니다.

근데 만약 pk를 id로 둔다면

JOIN Users u ON p.user_id = u.id

이런 형태인건데, 이게 틀린건 절대 아니에요. 근데 테이블이 많아진다면 가독성이 안좋아질꺼 같아요. 예를들면 이렇게 되는거죠

u.id
p.id
t.id
c.id

저는 개인적으로 가독성이 중요한 성격이라서 이 쿼리만을 보고 어떤 쿼리인지 의미가 명확하게 와닿지 않을꺼 같습니다.

자기참조 측에서를 고려해 볼까요?? 예를들어서 User가 이런 구조라고 해보죠

parent_user_id INT
FOREIGN KEY (parent_user_id) REFERENCES Users(user_id)

여기서도 사실 크게 다를바가 없습니다. 근데 만약 PK가 id라면??

FOREIGN KEY (parent_user_id) REFERENCES Users(id)

사용하는데에는 문제는 없지만 앞서 제가 말씀드린 저의 곤점에서의 모델링 문서나 ERD 작성 측면에서 명확성이 더 떨어지는거 같아요.

하지만 어디까지나 이건 제 취향일뿐 원하시는대로 해도 무방합니다. 사용하는데에 무방하고 취향적인 부분이 들어간 주제라고 생각해서 이걸 제가 맞다 틀리다라고 하고 싶지는 않아요.

질문 감사합니다!

인프런 AI 인턴

안녕하세요, 인프런 AI 인턴입니다. SJ님.

질문해주신 내용은 데이터베이스 테이블 설계 시 칼럼명, 특히 Primary Key의 명명 규칙에 관한 것입니다. 꽤 흥미로운 주제인데요, 테이블 설계 시 Primary Key를 어떻게 명명할지의 문제는 설계 철학이나 일관성, 가독성 등에 따라 달라질 수 있습니다.

Primary Key 명명 규칙

이름 규칙의 중요성:
- 테이블마다 고유한 식별자 칼럼을 PK로 두는 것이 일반적이며, 이를 id, user_id, post_id와 같이 명명하는 경우가 있습니다.
- Common Convention: 각 테이블의 식별자를 table명_id 식으로 정하여, 테이블 간의 조인이나 관계를 더 명확히 파악할 수 있습니다. 예를 들어, Users 테이블의 경우 user_id라고 명명하면 Users 테이블의 ID라는 것을 직관적으로 알 수 있습니다.
자기참조:
- 자기참조가 필요한 경우에도 id로 명명하여 사용해도 무방하지만, 특정 테이블 내에서 혼동을 피하기 위해 테이블명과 함께 명명하는 경우도 있습니다. 예를 들어, parent_user_id와 같이 명명하여 알아보기 쉽게 설계할 수도 있습니다.
명명 규칙의 일관성:
- 중요한 것은 명명 규칙의 일관성입니다. 조직 내 지원 팀에서 서로 다른 이해가 발생하지 않도록 명명 규칙을 정하고 이를 따르는 것이 좋습니다.
가독성과 확장성 고려:
- 코드 레벨에서 이를 파악할 때, 특히 외래 키 관계에서 사용자 테이블의 아이디인지 게시글 테이블의 아이디인지 헷갈릴 염려가 없도록 명명을 하는 경우가 있습니다.

이와 같은 원칙과 이유들이 Primary Key의 명명에 영향을 줄 수 있습니다. 좀 더 심화된 설명과 예시를 찾고자 하신다면, 다음의 자료가 도움이 될 수 있습니다:

데이터베이스 설계 가이드 - 테이블의 Primary Key 명명 원칙

위 링크에서는 데이터베이스 설계 및 테이블 간 관계의 명명에 대한 기본적인 가이드를 제공합니다. 강의에서 배우신 MySQL 및 데이터베이스 설계 지침을 바탕으로 더 나은 설계를 하시기를 바랍니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

작성한 질문수

전체 Q&A

질문하기