지난번에 이직한곳 db 구조 질문 올렸던 뉴비인데
이번에도 처음본 db 구조가 있어서 질문드림니다
흔한 n:m 테이블이 잏읍니다..
여기서 A 는 그냥 카테고리라 생가갛하고
b에서 여러개의 카테고리를 가지는 그런 구조라고 생각하시면 댑니다
근데이 n:m 테이블에 또다른 참조테이블을 연결함니다
뭐 여기까진 그냥 n:m 테이블에 추가로 다른 데이터 연결이 필요하니까 그런거 라고 이해할수 잏엇읍니다
근데 n:m이 참조하고있는 subData 라는 테이블에서 또다시 가지가 나눠집니다
저건 간략하게 표시한거지 실제론 저 another 테이블에 또다시 2번 3번 다른테이블을 참조하여
가지가 계속 나눠지는 형태로 되어잏읍니다
일단 제가 뉴비가 저런 테이블 구조를 처음봤으며
스키마를 보고 테이블이 저렇게 연결되어있다는걸 파악하는데에만 일주일정도 걸린거 같읍니다
이런 테이블 구조를 머라고 하나여? 관련 자료를 한번 학습해보고 싶읍니다
그리고 실제로도 저런 구조를 자주 쓰는편인가여?
일단 orm으로 쓰고있어서 쿼리자체는 본적이 업슴니다
Db 구조는 애초부터 전략을 짜놓거 구성했다가도 중간에 요구가 바뀌거나 유지보수 하면서 기능 추가하며 덧붙이며 이래저래 많이 바뀌니 “이런거 봤는데 많이 쓰니요?” 이런 질문은 무의미한듯 그냥 그대로 받아들여
뇌
툴 머임?
drawio같은데
저런거 말고 dbml이나 프리스마+삼촌꺼로 그려라…
기본적으로 AonB가 모든 테이블을 매칭 해주는 매칭 테이블이고 A나 B subData 모두 sub 테이블 / subData가 새로운 매칭테이블이 되서 그 밑에 하위 테이블들을 다시 매칭해주는 형태고 / 내가 볼땐 그냥 Tree 모델 생각하면 될 것 같음 / 계층이랑 depth 가 있고 AonB가 root 계층 0 depth, A B subData가 1계층, Another가 2계층이 되겠지 / Another 밑으로 또다시 가지치면 3계층 될테고 / 각 계층은 그냥 외래키로 연결하면 끝이고 / 근데 계층이 깊어지면 제일 밑의 하위 계층에서 root까지 올라가서 다른 가지로 넘어가려면 탐색시간이 오래 걸릴테니 계층이 깊어지지 않도록 전략을 짜야겠지
한 4계층 까지 내려가면 그냥 실패한 전략이라 보고 db 새로 짜는 식으로 이건 니네 비즈니스 모델에 따라 구조가 달라지겠지
자주 쓰냐고 묻는다면 엄청 흔한 타입 아닐까, rdb 쓰는데 저렇게 안짜면 뭐 어떤 구조로 짜는지 궁금함
A B another가 leaf가 될테니 각 매칭테이블 별로 leaf 개수도 고려해야 할텐데 무작정 depth 줄이자고 leaf 수 늘리면 관리할때 힘들어질 수도 있음
설명 감사드립니다 저정도까지 해본적이 없다보니까 좀만 깊어진다 싶으면 몽고db 써서 잘 몰랐음
db 새로 짤거면 leaf랑 depth 개수 변수로 놓고 파라미터 탐색기 돌려서 어느쪽이 시간이 제일 적게 걸리나 측정해봐라
파라미터 탐색은 또 뭐야 일단 저런구조가 익숙해지도록 계속 써보는거 부터 해봐야하고 아직 성능 따질 수준이 아니라서