연관 엔티티 네이밍 규칙

Question

안녕하세요! 연관 엔티티의 네이밍 기준(연결 강조 vs 의미 있는 이름)에 대한 강의를 듣고 고민이 생겨 질문드립니다.   강사님의 조언대로 처음에는 '의미 있는 이름'을 우선적으로 부여하고자 했습니다. 하지만 실제 설계를 진행하다 보니 다음과 같은 딜레마를 겪고 있습니다.   1. 직관성 저하 및 매핑 테이블 식별의 어려움 명확한 의미가 떠오르는 것만 의미형으로 짓고, 나머지는 연결 강조형(A_B)으로 설계했더니, 전체 ERD를 볼 때 어떤 테이블이 독립 엔티티인지, 어떤 테이블이 단순히 N:M 관계를 해소하기 위한 매핑 테이블인지 한눈에 파악하기가 어려워졌습니다. 규칙이 혼재되다 보니 오히려 일관성이 무너지는 느낌을 받았습니다.   2. 다중 다대다(N:M) 관계에서의 한계 그렇다고 매핑 테이블의 일관성을 위해 모두 '연결 강조형(A_B)'으로 통일하자니, 두 엔티티 사이에 여러 개의 M:N 관계가 존재할 때 문제가 발생했습니다. 예를 들어, User와 Store 사이에 '찜하기', '방문 내역' 등 여러 맥락의 관계가 존재할 경우, 단순한 user_store 라는 이름만으로는 이 관계들의 성격을 전혀 대변할 수 없었습니다.   보통 실무에서 이러한 상황일 때, 일관성(매핑 테이블임을 명확히 인지)과 의미(어떤 맥락의 관계인지 표현)를 모두 충족시키기 위해 주로 어떤 네이밍 패턴이나 타협점을 사용하시는지 실무 노하우가 궁금합니다!

communityai8509 · Answer

안녕하세요, 인프런 AI 인턴입니다. 박도현님. 연관 엔티티의 네이밍은 프로젝트의 복잡도와 팀의 컨벤션에 따라 다르게 접근될 수 있습니다. 강사님의 강의 내용을 바탕으로 연관 엔티티의 네이밍에 대해 몇 가지 방법을 추천드리겠습니다. 직관성과 의미의 균형 맞추기 : 연관 엔티티를 명명할 때, 우선적으로 해당 엔티티의 역할이나 의미를 고려해보세요. User_Store_Wishlist , User_Store_VisitHistory 같은 이름은 관계의 의미를 명확히 하면서도 매핑 테이블임을 나타낼 수 있습니다. 네이밍 규칙 확립 : 팀 내에서 네이밍 컨벤션을 확립하여 일관성을 유지하는 것이 중요합니다. 예를 들어, &lsquo;A_B_기능&rsquo; 형태로 매핑 테이블을 명명하면, 이는 둘 간의 관계를 설명하면서도 각 엔티티의 주요 역할을 파악하는 데 도움이 될 수 있습니다. 컨벤션 문서화 : 팀의 네이밍 컨벤션을 문서화하여 누구나 참조할 수 있게 하면 개발자 간의 혼란을 줄일 수 있습니다. 이는 신규 팀원이 프로젝트에 뛰어들 때도 큰 도움이 됩니다. 연관 엔티티 네이밍 규칙에 대해 더 깊이 있는 사례를 찾고자 하신다면, 다음의 유사한 질문과 답변을 참고해 보시길 추천드립니다: M:N 관계의 연관 엔티티 설계 순서 연관 관계 매핑 실무 원칙에 대해 질문 저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.