https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=184186527
이 책을 읽고 있다. 정규화가 엄------------청 길게 나오길래 '아... 이걸 다 읽어야하나?' 싶었다.
DB 조회할 때 Join 은 비용이 아주 큰 연산이라 최대한 지양하는데, 정규화를 시키면 조인을 할 수밖에 없는 상황이 있다.
디스크 가격이 비쌌던 과거에는 공간 복잡도를 조금이라도 줄이기 위해 정규화가 절실했을 것이고
SQL 을 직접 날려서 데이터를 관리한다면 무결성을 위해서 정규화가 필요했을 거라 생각한다.(요즘은 ORM으로 많이들 하잖아!)
근데 지금은 디스크 가격이 엄청 싸져서 NoSQL로 객체 그대로 때려박아도 긍정하는 세상아닌가!
가만히 앉아서 조금만 더 생각해보니까
디비 필드가 몇 십개나 되면 조회할 때 필요없는 칼럼까지 다 들고와야 하니까 시간이 엄청 걸리고, 디비를 직접 눈으로 보면서 디버깅 하기도 힘들다.
정리하자면 케바케(Case By Case) 라는 것.
조인을 절대 해서는 안되는 환경이라면 NoSQL을 쓰는 게 하나의 선택지가 될 수 있고, 공간 복잡도를 줄여야 하거나 칼럼이 너무 많다면 정규화를 하는게 나을 수도 있다.
그러니 결국... 이 긴 정규화 파트를 다 읽어야 한다는 뜻이다 ㅠㅠㅠㅠ
'개발' 카테고리의 다른 글
Hibernate 6.0 Final 릴리즈!! (0) | 2022.04.05 |
---|---|
'코드 리뷰의 정수'라는 글을 읽었다. (0) | 2022.04.03 |
「도메인 주도 설계 핵심 」을 읽고, 잘 모르겠다! (0) | 2021.10.16 |
[Scala] 스칼라는 예외를 이용하지 않고 오류를 처리한다. (0) | 2021.06.30 |
[Scala] 다형성 [T]는 컴파일 타임에 사라진다. (0) | 2021.06.20 |