11/12 - TIL : git merge와 rebase, 반정규화

 

오늘 git 그리고 PR이라는 특강을 들었다. 

 

그 중에서 가장 기억에 남았던 git merge와 rebase에 대해 정리해보려고 한다. 

merge vs. rebase

• merge : 새로운 커밋(merge commit)을 추가하여 브랜치를 합침 
  • 각 브랜치의 히스토리(commit)이 그대로 유지되며 합친 흔적(merge commit)이 남는다. 
• rebase : 특정 브랜치 위로 다른 브랜치의 커밋을 다시 적용하여 합침 
  • 하나의 브랜치에서 모든 작업이 이뤄진 것처럼 깔끔하게 보인다. 

 

프로젝트를 해봤을 때 merge도 사용해보고 rebase 사용했었다.

팀이 어떤 전략을 선택해서 그것을 잘 따르는 것도 중요하다고 생각한다. 하지만, 가장 중요한 것은 merge, rebase 상관 없이 conflict를 잘 해결하는 것이라고 생각한다. (conflict가 가장 무섭다..)

 

 

오늘 반정규화와 관련한 이슈를 팀원들과 다루었다. 

 

Shop(가게)와 Order(주문) 사이의 연관관계가 없어, 주문이 들어왔을 때 가게 정보를 어떻게 전달해야 하는지에 대한 이슈였다. 

 

제안된 방법은 2가지였다.

1. 연결된 테이블에서 Join을 통해 가져온다. 
2. Order 테이블에 shop_id 값을 저장하는 컬럼을 추가한다. 

첫 번째 방법은 정규화 상태를 유지하며 데이터의 중복을 줄인다. 따라서, Shop의 shop_id가 변경되더라도 Order에서 일관성을 유지할 수 있다. 하지만, 여러 번의 Join은 쿼리를 복잡하게 만들며 성능을 저하시킬 수도 있다.

 

두 번째 방법은 Order 테이블에 바로 shop_id를 추가하기 때문에, Join 없이 바로 데이터를 가져올 수 있다. 따라서, 쿼리가 간단해지고 성능도 좋다. 하지만, Shop의 shop_id가 변경될 경우, Order의 shop_id도 변경되어야 한다. 이는 만약, shop_id가 자주 변경되는 컬럼이라면 데이터의 일관성을 해칠 수 있다. 

 

반정규화?

정규화된 엔티티, 속성, 관계에 대해 시스템의 성능향상과 개발과 운영의 단순화를 위해 중복, 통합, 분리 등을 수행하는 데이터 모델링의 기법

 

 

내 생각은 2번째 방법을 사용하는 것이다. Shop의 shop_id가 변경될 가능성이 적기 때문이다. 

 

하지만! 뭐든 비교를 통한 선택이 가장 좋다고 생각한다. 비교를 통한 과정 속에서 내가 모르는 새로운 것을 배울 수도 있고, 선택에 대한 이유가 생기기 때문(중요하다고 생각)이다.