정규화는 항상 옳은가 ? Join 은 정답일까?

 

데이터 베이스의 정규화는 데이터의 중복을 제거하기 위하여 진행을 한다.

 

데이터의 중복을 없에는 것은 꼭 자원을 효율적으로 사용을 하는 것 이라고 할 수 가 있을까 ?

 

-> 두가지의 테이블을 만들어 fk 를 통한 join 도 비용이라는 것을 알아야한다.

 

즉 , 정규화와 비정규화의 tradeOff 에 앞서 도메인 이해를 바탕으로  조회용 데이터와 쓰기 용 데이터를 먼저 구별을 하는게

올바른 설계의 첫 걸음이라고 생각이 든다.

 

정규화의 장점 

1. 중복을 제거

2. 데이터를 한곳에서 관리

3. 데이터 정합성 유지가 쉽다

 

비 정규화의 장점

참조 없이 읽기가 가능하다. 

 

 

정규화를 언제 사용하는게 효과 적일까 ?

 

데이터의 최신성을 고려한 판단이 하나의 기준이 될 수 가 있다. 

 

사용자의 이름과 닉네임 고유한 식별자가 있는 테이블에서 ,

 

사용자의 닉네임의 변경 기록을 저장하는 또다른 테이블이 있다라고 가정을 하자.

 

사용자의 과거 데이터를 가지고 있는 변경 기록은 정규화를 이루어지게 하지 않아도 된다,

 

사용자의 아이디와 과거부터 현 사용중인 닉네임 까지 모두 하나의 테이블에서 가지고 있는 모습을 이루게 된다.

 

또다른 하나의 기준은 , 팔로우 기능을 생각 해볼 수 가 있다. 

 

파로워의 목록은 최신을 유지를 해야하는 상황이며 1000 만 팔로워를 거느린 유명인이 닉네임을 바꾸는 상황을 생각했을떼 , 팔로우 테이블에는 닉네임이 들어가지 않은 정규화가 이루어진 테이블 설계를 한다.

 

추가로 msa 를 생각을 하여 도메인간의 결합도를 낮추는 것을 생각하고 , 미래의 유연한 설계를 위하여 join 을 사용하지 않고 쿼리를 하나 더 날리는 상황도 고려 해볼만 하다 라고 한다.

 

조회시 성능이 좋은 별도의 데이터 베이스나 캐싱등 다양한 최적화 기법을 이용할 수 있다.