데이터베이스 구성할때
그냥 한테이블에 필요한 속성 때려넣는게 낫나요
아니면 테이블 분리해서 조회할때 join을 하는게 낫나요
한테이블에 필요속성 때려넣는건 유지보수하기에 헬인거같은데 조회할땐 괜찮아보이고
테이블 분리해서 join할땐 연관된 테이블 많아지면 연산량 많아져서 ㅈㄴ 느려질거같은데 유지보수하기엔 괜찮아보이는데
일단 제가 생각한게 맞는지와 어떤 방법이 나을지 질문드립니다.
챗지피티는 걍 나누라고 하긴하네요
예를 들어서 포켓몬 도감을 만들고 싶다하면
포켓몬 영문이름이랑 한글이름을 포켓몬이라는 테이블에 한꺼버넹 떄려넣기
vs
포켓몬 테이블엔 영문이름만 넣고 이름테이블을 새로 만들어서 랭귀지 속성이랑 이름 속성 넣어서 나라별 이름 정리한 테이블 만들기
그건진짜 상황따라 다른건데
반정규화 하냐 정규화 하냐의 문제네 - dc App
정규화 해놓고 아시발성능 소리 나오면 반정규화 고민하기
비즈니스를 정확하게 이해하고 정규화 수준에 따라 조회시 성능을 예상해서 결정하는거에요 - dc App
+ 확장용이성 필요정도에따라 - dc App
예시같은경우국가가 많으면 정규화 하는게 낫고또애초에 글로벌한 서비스는 레이턴시 때문에 리전별로 데이터베이스를 구성해서 사용하기 때문에문화권끼리 묶어서 데이터베이스를 구성하고그내에서 정규화한 이름테이블을 사용할 수도 있을듯 - dc App
그리고 큰서비스 일 수록 비정규화로 얻을 수 있는 이점이 점점 줄어들어 내역 이나 목록케이블 같은경우에 행수가 엄청나게 될텐데 비정규화된 테이블 일수록 로우사이즈 때문에 페이지당 저장할 수 있는 행의 갯수가 줄어들어서 결국엔 같은 scan을해도 많은 페이지를 읽어야 하고 인덱스 트리의 깊이도 로우사이즈에 따라서 늘어나기 때문에 조건에 해당하는 데이터를 찾아가는데도 비용이 증가하게 돼 - dc App
그래서 거의 대부분의 엔티티는 2~3정규화를 만족하는게 가장 성능이 좋고 대략적으로 그나마 비정규화가 유리한 엔티티는 설정값 테이블 같이 해당 기능에서 조회될 행이 1개이거나 거의 적은 경우 그리고 확장성 용이를 생각해서 과도하게 정규화된 테이블 정도 - dc App
근데 예시같은 컬럼이 그수가 적고 그렇게 큰서비스가 아니라면 비정규화 해도 크게 상관없을듯 - dc App
토이 프로젝트 정도할때는 정규화든 비정규화든 크게 차이 없겠네유 그냥 정규화를 연습하는 정도로만 하는게 낫겟네요