잘 못 되었거나 개선해야하는 부분이 있을까요?
1 Like
어떤 목적의 프로그램을 위한 데이터베이스인지 충분한 설명이 없으면 답을 얻기 어려우실 겁니다.
1 Like
도메인 특성을 몰라 틀릴 수도 있지만, 우선 같은 스키마를 갖는 테이블이 복수로 존재하는 점이 눈에 띕니다.
Address,
BranchAddress,
MemberAddress
쿼리 효율을 중요시한 결정일 수도 있으나, 보통 요구되는 아래의 조건에 대한 대응이 부족해 보입니다.
하나의 Address 에 복수의 Personal 이 있다.
하나의 Address 에 복수의 Branch 가 있다.
하나의 Address 에 복수의 BranchMember 가 있다.
저 같으면, BranchAddress 와 BranchMemberAddress 를 두지 않고, N:N 관계를 표현하는 조인 테이블을 추가할 것 같습니다.
PersonalAddress
- Id : int (Sequence)
- PersonalId : int (FK to Personal.PersonalId)
- AddressId : int (FK to Address.AddressId)
- (PernalId, AddressId) (PK)
BranchAddress
- Id : int (Sequence)
- BranchId : int (FK to Branch.BranchId)
- AddressId : int (FK to Addres.AddressId)
- (BranchId, AddressId) (PK)
BranchMemberAddress
- Id : int (Sequence)
- BranchMemberId : int (FK to BranchMember.BranchMemberId)
- AddressId : int (FK to Address.AddressId)
- (BranchMemberId, AddressId) (PK)
그런데, Branch Member 는 Branch N : N Personal 을 표현하는 조인 테이블의 개념으로 봐야 할 것 같습니다.
BranchMember
- Id : int (PK)
- PersonalId : int (FK to Personal.PersonalId)
- BranchId : int (FK to Branch.BranchId)
- JoinedDate : DateTimeUtc
- LeftDate : DateTimeUtc (Nullable)
- Title : Vachar
- BranchManagerId : int (FK to BranchMember.Id)
2 Likes
제가 설명을 안적어두었네요 ㅠㅠ
좌측에 테이블은 HeadOffice(본사) 우측은 각 지점별 테이블을 입니다.
일부러 HeadOffice와 Branch를 구분 해둔 것이구요.
Address부분은 저도 하나로 통합할까 고민했었는데, 효율을 따져보다가 분리하는 것이 맞는 것 같아 분리했습니다. 답변감사합니다. ㅎㅎ
작성해주신 내용 참고해보겠습니다. ㅎ
본사와 지점간의 직원, 급여 매출 관리 등을 목적으로 하고 있습니다.
하나의 스키마를 복수의 테이블로 쪼개는 것은 역평탄화(Denormalization) 중 하나입니다.
역평탄화의 장점은 성능이지만, 그에 대한 비용이 만만치 않습니다.
질문의 관계도에는 그 비용을 치룬 흔적이 전혀 안 보입니다.
제가 포플을 받는 입장이러면, 그 비용에 대해 설명하고, 어떻게 대비해야 하는 지 물을 것 같습니다.
4 Likes
안녕하세요
많이 부족한 주니어 개발자 입니다.
몇 가지 궁금한 점이 있어서 문의드립니다.
- (BranchMemberId, AddressId) (PK) 이와 같이 복합키가 있는데 Sequence를 따로 두는 이유가 궁금합니다.
- 언급 해주신 비용 부분이 이해가 가질 않는데… 괜찮으시면 조금만 더 부가설명을 해주시면 진심으로 감사드립니다…!
2024년도 고생하셨습니다!
2 Likes
시퀀스는 보험용 입니다. 저 테블이 어떻게 성장할 지는 아무도 모르기때문입니다.
역직렬화 비용에 대해서는 이론과 실무가 쌓여야 알 수 있는 주제라서 탐구해보시길 권해드립니다
3 Likes
실무에선 외래키 잘 안쓴다고 하면 놀라시겠죠?
2 Likes
전 학생시절에 학교에서 배웠던 내용을 복습하고 포폴을 만들면서 DB를 모델링해왔습니다. 아직 완성된 설계가 아니기 때문에 저도 어떻게 더 바꿔야할지는 모르겠지만… 현재 제가 진행하고 있는 모델링은 학교에서 배운 내용으로 진행하고 있습니다.
일단 많이 말씀해주신 Address부분이 3테이블로 나누어지는데, 이는 많이 고민했습니다. 하나로 합칠까?
구현된 사이트에서 보면 사용자는 본사 직원만 들어올 수 있고, 지점직원은 접속이 불가능하기 때문에, 분리를 했으며, 지점과, 지점 직원간의 address부분은 데이터를 불러올 때 두개를 하나로 합쳐서 두 데이터를 비교하는 것보다 각기 다른 테이블에서 가져오는 것이 빠를 것이라 생각했습니다.
헐… 정말인가요?
N:N 관계로 설정한다면 위 테이블을 가지고 보았을 때
BranchAddress를 → Address로 통합하고
Address와 Branch 그리고 Members를 이어주는 브릿지 형식의 테이블을 추가한다는 말씀이신가요?
AddressMember란 테이블에는
PK AddressMember ID int
FK MemberID int
FK AddressID int
AddressBranch에는
PK AddressBranchID int
FK AddressID int
FK BranchID int
와 같이 말씀인지 궁금합니다.
답변 감사합니다.
1 Like