특별한 사유가 없다면 비식별관계로 설계하자
식별관계로 설계했다가 피본건 아니고
조언 듣고 비식별관계로 만든 덕분에 기능확장이 수월해져씀
인조식별자를 쓰면 유니크 제약조건도 따로 걸어줘야하고
클러스터링 인덱스를 활용하지 않게 돼서
오버헤드만 증가시키고 낭비가 아닌가(하면서도 계속 씀ㅋㅋ)
하는 의문을 가졌었는데
만약 그랬다면 길을 더 돌아가야 했을지도
식별관계로 설계했다가 피본건 아니고
조언 듣고 비식별관계로 만든 덕분에 기능확장이 수월해져씀
인조식별자를 쓰면 유니크 제약조건도 따로 걸어줘야하고
클러스터링 인덱스를 활용하지 않게 돼서
오버헤드만 증가시키고 낭비가 아닌가(하면서도 계속 씀ㅋㅋ)
하는 의문을 가졌었는데
만약 그랬다면 길을 더 돌아가야 했을지도
처음할 땐 식별, 비식별 뭐가 좋은지도 모르고 막 설계했다가 나중에 프로젝트 절반 쯤에 아 씨발 이거 이렇게 설계하면 안되는구나 싶어서 갈아엎으려고 했지만 늦음.. 본인 경험임;
난 놀랍게도 취직해서야 깨달음
나도 고민 많이 했는데 사소한 오버헤드를 걱정해서 유지보수성과 확장성을 해치는건 망하는 지름길이다 라는 말을 새겨듣고 결정했었음ㅋㅋㅋ
학교 수업에서는 이론은 이렇지만 실무에서는 어떻게 써야 한다~ 까지는 안알려주니까 보통..ㅜ
db는 하면 할수록 너무 어려움;
개엠생 시절에는 정규화만 어렴풋이 알고 있다가 공부하니까 반정규화는 니미 씨발 뭔소리임? ㅋㅋㅋ 갑자기 성능 떨어진다고 다시 나눠놨던 테이블 합치고 고려할 것도 너무 많고 머리아픔..
애매한게 너무 많아 반정규화 정규화 전부 필요하다고보는데 적재적소를 가려내기에 내 역량이 너무 부족하다
공부만이 살길이다.. 지금도 퇴근하고 와서 공부하다가 집중 안되서 자기 전에 그냥 갤질하는 중
솔직히 데이터베이스 설계자체가 트레이드오프느낌으로 오버헤드를 지불하고 확장성을 받은 느낌이고.. 정규화같은것도 그런느낌이지 DBA들은 무슨 생각을할까 - dc App
오버헤드가 과해지면 또 바꿀텐데 전문 dba를 만나본적이 없어서 조언을 못하겠네 - dc App
일단 지금은 대용량 조회가 빈번하게 호출되는 테이블은 아니라서 괜찮은거 같음. DBA랑 개발자랑 입장이 다른 부분들도 꽤 있는것 같더라. 외래키 같은 것도 그렇고
정규화 반정규화도 지금 고민인 영역이긴함ㅋㅋ
dba랑 개발자는 입장이 같아 같아야만 해
그런가 그럼 내가 본 DBA가 좀 특별한 생각을 가진걸수도 있겠네
현직에서 개같이 구른 개발자들이 2차전직으로 dba하는거 아니였음? 걔들이 처음설계할때 초반 고려대상 우선순위가 궁금 - dc App
dba는 이론적인 데이터 구조에 집착하면 안되고 실제로 데이터가 어떻게 저장되고 쓰이는지에 대한 이해를 가지고 있어야함 이해가 부족하면 개발자랑 소통해서라도 이해를 쌓아야지 그리고 데이터 모델링은 전문 데이터 모델러 아니고서야 개발자가 dba보다 잘함 거기서 성능 튜닝 할만한거나 dba가 좀 봐주는거지
테이블 설계는 1차적으로 개발자가 하는거임 왜냐면 어떤 데이터가 필요한지는 개발자가 잘 아니까 대규모 시스템 설계할때는 데이터 모델러가 개발자랑 커뮤니케이션 해서 테이블 설계해주기도 함