여태 스프링만 쓰다가 지금 학교에서 디비 수업듣는데 뭔가 괴리감이 든다.
예를 들어 직원엔티티와 부서엔티티가 있다면 스프링할때는
그냥 직원 속성에다가 fk넣고 부서pk 참조하는식으로 했는데
교수가 무조건 엔티티는 관계가 있어야된다고 엔티티끼리의 직접 연결은 없다고
중간에 work_In 관계 엔티티가 필요하다라고 설명함. work_In 관계엔티티에서 직원pk, 부서pk참조하는식으로.
이렇게 또 적용하다보니까 Item이 있고 Image엔티티가 있으면 이것도
Item_Image 엔티티로 관계 엔티티로 두개 엔티티 관계맺어야되는거임???
교수 현업뛰고있는거로 알아서 믿고가려고했는데 여태 스프링에서 해온 버릇이 있어서 헷갈리노..
아 그리고 추가로 관계엔티티로 모든 엔티티 연결하면은 fk를 구지 직원속성에 넣어야되나?? fk가 언제 필요한거임??
헛솔임 걸러들으삼
어디학교임?
건동홍라인임 대학교재에도 저렇게 설명되어있긴한데 인터넷이나 책보면 직접 fk참조하던데..
ㅎ이신가요 혹시
zz
ㅇ디비 들음? ㄱ디비들음?
아 나는 2-2임 ㅋㅋ 왠지 본문이 ㅇ디비인거같아서 물어봤음
2-2인데 ㅇ디비 내용 어떻게앎??
n:n이면 중간에 끼는게 맞음 1:n이거나 1:1이면 그럴필요없는디
서로 n:m 관계이거나 1:n 이라고 하더라도 이력을 관리해야 한다면 중간에 릴레이션 테이블을 둬야 하는 게 맞다. 그리고 토이 프로젝트가 아닌 '진짜' 사내 시스템이라는 것은 실제로 그런 관계를 가지기 때문에 중간에 관계 엔티티를 두는 게 일반적이다. 테이블의 이름은 발령이 되겠지. 이런 걸 염두에 두지 않고 개발을 하게 되면 꼭 과거 데이터 뭐 어쩌고 할 때 이력이 안 남아있어서 그거 못 구하는데요 이따위 무능력자의 핑계를 대게 된다. 굳이 사원-부서 관계 뿐만이 아니라. 사실 1:n이라고 생각하는 대부분의 관계는 이력 개념이 나중에 가면 꼭 들어갔어야 했다는 사실을 뒤늦게 깨닫는 경우가 많아서 앵간한건 정말로 n:m인 게 맞다고 보면 된다.
개추
아이템과 이미지도 전형적인 n:m 관계다. 정확한 업무 요건을 알 수 없어서 확정적으로 말할 순 없지만 보통은 하나의 아이템이 여러 이미지를 가질 수 있고 하나의 이미지가 여러 아이템에 참조될 수 있기 때문에. 어거지로 1:m으로 하자면 사실 같은 이미지인데 매번 id를 다르게 따서 넣어야 한다거나 하는 일이 발생한다. 무의미한 데이터가 늘어나고 정합성에도 맞지 않고 심지어 이미지를 하나만 저장할 걸 같은 이미지를 매번 id를 다르게 따서 저장한다거나 하는 일이 발생할 수도 있겠지.
오 좀 이해됐어요 이력을 나타내기 위해서는 따로 릴레이션 테이블로 두는게 맞다는거잖아요?? 관계 릴레이션에서 속성값들을 추가해서 이력을 더 잘 나타낼 수도 있는거고
그럼 외래키로 엔티티끼리 직접 참조는 거의 안하나요?? 관계엔티티에서만 참조해도 조인으로 서로 다 참조가능할거 같은데
맞음. 특히 관계 테이블에 넣두면 나중에 좋을 칼럼들이 start_date나 end_date 같은 것들이고. 그리고 직접 참조하는 일도 당연히 많음. 말이 앵간한건 이라고 표현하긴 했지만 1:m 이라고 생각했던 것들이 나중에 가보면 n:m으로 관리해야 했었구나 라는 걸 뒤늦게 깨닫는 일이 참 많다 보니까 적당히 과장해서 표현한 거고 실제로는 진짜로 1:n인 것들도 당연히 흔하니까 그런 것들은 직접참조 하는 거지. 그리고 n:m 관계라고 하더라도 직원 엔티티에 부서 pk를 넣는 게 크게 이상한 건 아님. 왜냐면 굳이 따지자면 반정규화긴 하겠지만 현재부서 정도는 그냥 직접참조할 수 있다는 거지. 매번 정규화를 철저히 해서 n:m인 건 다 중간테이블 만들고 그러면 개발하기 불편하고 성능에도 문제가 있으니까.
다 관계엔티티 두는게 정규화정석이지만 그만큼 조인되는 엔티티도 많기 때문에 적절히 상황에 따라서 트레이드 오프하면되는거네요? 실제로 현업에서도 두개 섞어쓴다고 보면되겠네요? 감사합니다.
ㅇㅇ. 그런데 현업에서 너무 철저하게 정규화 원칙을 지키지는 않는다는 것은, 사원 엔티티에 부서 pk를 빼는 정도의 원칙까지 철저히 지키는 건 아니고 필요에 따라 넣는다는 것이고 중간 엔티티를 뺀다는 말은 아님. 곰곰히 생각해 봐서 나중에 이력 개념이 들어간 데이터가 필요한 일이 발생할 거 같으면 앵간하면 중간 엔티티를 넣어야 함. 선택할 만한 건 직접참조 칼럼을 원칙에 따라 뺄 거냐 적당히 편하게 개발하기 위해서 넣을 거냐 정도고 중간 엔티티를 상황에 따라 넣을 수도 있고 안 넣어도 되고 이건 너무 안이한 태도라서 어지간하면 넣어야 함. 선택의 여지가 없음. 왜냐하면 당시 시점의 데이터가 필요하다든가 하는 이력개념이 들어간 업무요구사항은 거의 대부분의 경우 언젠가는 반드시 필요한 날이 요기 때문에
아하 사실 대부분 업무상 데이터 기록은 남겨야하니까 현업에서는 중간 엔티티를 거의 대부분 만들고 여기서 선택사항이 정규화를 어기더라도 fk를 두고 직접 참조하냐 안하냐정도라는거네요
현실이랑 학교에서 배우는거랑 좀 다르니까 학교에서 탄탄히 다져놔
윗댓말대로 인스타급 유저수 아니면 인덱싱해서 성능 차이 별로 안나기땜에 걍 다대다 상정하고 만드는게 나음