칼럼명

Question

-- 유저 테이블 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 컬럼명으로 하신 이유가 있나요 ?

Hong · Answer

안녕하세요 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 작성 측면에서 명확성이 더 떨어지는거 같아요.     하지만 어디까지나 이건 제 취향일뿐 원하시는대로 해도 무방합니다. 사용하는데에 무방하고 취향적인 부분이 들어간 주제라고 생각해서 이걸 제가 맞다 틀리다라고 하고 싶지는 않아요.   질문 감사합니다!

communityai8509 · Answer

안녕하세요, 인프런 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 및 데이터베이스 설계 지침을 바탕으로 더 나은 설계를 하시기를 바랍니다. 저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.