해결된 질문
작성
·
187
0
학습 관련 질문을 최대한 상세히 남겨주세요!
고민 과정도 같이 나열해주셔도 좋습니다.
먼저 유사한 질문이 있었는지 검색해보세요.
인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요.
Comment 엔티티 생성시 연관관계를 Long articleId로 해줌으로써 Article 엔티티와 연관관계를 맺어준것일까요?
Article과 Comment는 1:N 관계로 보이는데, comment 테이블 설계 당시 Article에 대한 외래키 관리를 comment 테이블에서 안해준 이유도 궁금합니다.
답변 3
1
철현님, 안녕하세요!
Comment의 articleId가 Article과 연관 관계를 맺어준 게 맞습니다.
어떤 부분에서 안해주었다고 느끼신 부분일까요?!
혹시 JPA의 @OneToMany, @ManyToOne 이러한 연관 관계에 대해서 말씀하시는 것일까요?
DB 관점에서 생각하고, JPA에 종속된 사고는 벗겨내야 한다는걸 말씀드려봅니다!
(요즘 대부분의 취준생/주니어 분들이 DB보단 JPA에만 초점이 맞춰진 경우가 많아서 누차 말씀드려봅니다..!)
일단 강의는 MSA 환경에서 진행하고 있습니다.
그렇기 때문에 댓글 서비스와 게시글 서비스는 물리적으로 완전히 독립된 애플리케이션입니다.
멀티모듈 구조라서 단일 프로젝트에서 공통 모듈(코드)을 공유하면서 여러 애플리케이션을 띄울 수 있을 뿐이지,
각 애플리케이션의 코드베이스도 격리되어 있다고 볼 수 있습니다.
뿐만 아니라, 데이터베이스도 격리되어 있습니다.(comment DB, article DB)
따라서 댓글 서비스는 게시글 서비스의 코드를 의존하고 있지도 않고, 엔티티 클래스를 직접 참조할 수 없습니다.
참조 키를 가짐으로써 연관 관계가 맺어져있다고 볼 수 있습니다.
그리고 실무에서는 락, 성능, 스키마 관리의 어려움 등을 이유로,
테이블 제약 조건의 외래 키는 걸지 않는 경우가 많습니다.
단순히 참조 키로만 관리하는게 일반적입니다.
(클래스 코드 레벨에서는 DDD/aggregate 이런 개념이 잡히면, 객체로 연관 관계를 맺는 경우도 있으나, 이건 일단 논외로 하겠습니다.)
아래 질문 1번 답변과 동일한 의문이신 것 같아서 다시 공유 드려봅니다!
https://www.inflearn.com/community/questions/1504157
혹시 더 궁금한 점 있으시면 편히 문의 주세요!
0
그냥 단순히 컬럼에 article_id를 넣어줌으로써 테이블간에도 연관관계가 맺어졌다고 볼 수 있나? 라는 의문이 들어서 여쭤본거긴 합니다.
강사님 설명 들으니 이해가 되네요 comment 테이블에서 article_id를 참조함으로써 연관관계가 맺어진걸 알 수 있는데, 그럼 혹시 제약조건을 걸지 않는 이유가 뭘까요?
배우는 입장으로서 학습할 때 제약조건을 걸어야 참조 무결성을 유지한다고 알고있는데 실무에서는 제약조건없이 참조만 하는 이유를 알고싶습니다
실무에서는 제약조건없이 참조만 하는 이유
답변에 모두 포함되어 있긴한데 너무 장황하게 말씀드렸네요.. ㅎㅎㅎ
아래처럼 다시 정리해보겠습니다!
제약 조건으로 인해 쓰기 성능 저하(제약 조건 확인이 필요하기 때문)
제약 조건으로 인해 스키마 변경의 어려움(실무에서는 요구사항이 변화하며 스키마를 변화하는 상황이 생길 수 있는데, 제약 조건이 걸려있으면 참조 테이블로 인해 변경이 제한되고 유연하지 않음)
물리적으로 분리된 데이터베이스(강의에서도 MSA 진행하며 DB는 분리되었다는 관점입니다)
DB의 종류 자체가 다를 수 있습니다(게시글은 MongoDB/댓글은 MySQL을 선택해야하는 상황이 생길 수도 있습니다.)
성능/유지보수/유연함 등으로 인해 물리적 제약은 사용하지 않는 경우가 많습니다.
정말 엄격한 제약이 요구된다면 또 다를 수 있는데, 위처럼 문제가 많다보니 물리적 연관 관계 제약을 사용하는건 극히 드문 것으로 알고 있네요.
참조 무결성은 중요하지만, 애플리케이션에서 처리하는 것으로 충분할 수 있습니다.
아주 낮은 확률로 일부 깨질 수 있더라도, 차라리 모니터링 등으로 수동 대응하는 것이 더 나은 상황도 많습니다.
0
안녕하세요, 인프런 AI 인턴입니다. 박철현님.
스프링 부트로 대규모 시스템을 설계하면서, Comment와 Article 엔티티 간의 연관 관계 설정에 대해 질문 주셨군요. 질문하신 내용은 일반적으로 엔티티 간의 관계 설계에서 중요한 부분입니다. 이와 관련하여 몇 가지 설명을 드리겠습니다.
연관 관계의 설정:
Long articleId
를 사용하여 Article 엔티티와의 관계를 설정한다면, articleId 필드를 통해 간접적으로 연관 관계를 맺는 것입니다. 이는 데이터베이스 설계에서 실제 외래 키를 설정하지 않고, 관계를 코드 레벨에서 관리하는 형태로 볼 수 있습니다.@ManyToOne
, @OneToMany
등의 어노테이션을 사용하여 관계를 나타내며 외래 키를 명시적으로 선언하곤 합니다.Foreign Key Constraint 사용 여부:
유연한 설계 고려:
이와 관련한 구체적인 상황 설명이나 실전 사례를 원하신다면 아래 유사한 주제를 다룬 인프런 게시물을 참고하여 더 많은 정보를 얻으실 수 있습니다:
- Entity Relationships in JPA and Best Practices (게시글 제목)
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
네, 맞습니다!
참조키를 가지고 있음으로써 연관 관계가 맺어졌다고 볼 수 있습니다.
이에 대한 검증은 애플리케이션에서 처리해야 할 몫입니다.
데이터베이스의 물리적인 제약 조건은 사용하지 않습니다.
물리적인 제약 조건을 사용하게 되면 제한되는 부분이 많습니다.(성능/유지보수 등)
또, 실무에서는 각 모델들을 다양한 요인에 의해 동일 DB에 넣지 않을 때도 있고, DB 종류조차 아예 다를 수 있습니다. 이런 경우에는 데이터베이스의 제약 조건을 아예 사용할 수도 없습니다.
관점에 대해 한 단계 더 나아가면,
각 엔티티를 관계형 데이터베이스의 스키마로 생각할게 아니라, 단순히 데이터 모델의 관점으로 보실 수 있습니다.
게시글은 MongoDB/댓글은 MySQL에 넣더라도,
댓글이 게시글 ID를 가진다면 연관 관계가 맺어진 것입니다.
논리적/물리적 연관 관계에 대해서도 생각해보실 수 있을 것 같네요.
데이터베이스의 물리적 연관 관계는 맺어지지 않았지만, 참조키를 통해 논리적 연관 관계는 맺어진 상황입니다.