팀 노션 링크 -> 팀 노션
WMS 창고관리시스템을 리팩토링 하기 위해 "도넛팀"이 모였다!
기존 5인 -> 3인으로 팀원이 변경되면서 아쉽게 기능 개발에서 제외된 친구들을 도입해보기로 했다.
그리고! 기획하고 구현하면서 많은 고민들을 했는데 기록으로 남기지 않아서 잘 기억이 나지 않는다...
앞으로 고민한 사항들 모두 정리하겠습니다! ! !
유통기한
먼저 제품의 "유통기한"을 도입하기로 했다. 도넛은 식품이다 보니 유통기한이 필수!
제품이 입고되면 제품의 보관 카테고리별로 유통기한을 부여한다. (입고일 기준 + 알파)
ex) 냉장+3, 냉동+7, 실온+365
Q1. 유통기한을 재고 테이블에 어떻게 보관할까?
A1. 기존 재고코드는 창고+제품 코드를 합친 복합키 형태로 구성되어 재고코드만 보고 어느 창고의 어떤 제품인지 알 수 있게 만들었다.
Q2. 그렇다면 유통기한 컬럼을 기존 재고 코드처럼 (재고코드 = 창고+제품+유통기한) 만들어야 되나?
A2. 여기서 2가지 방안을 생각함
- 재고코드 = 창고+제품+유통기한
- 재고코드 = AutoIncrement, 유통기한 컬럼 추가
1. (창고+제품+유통기한) 자체를 PK로 사용
장점은 직관적인 의미 파악... 외에는 없어 보인다.
단점
- PK 길이 증가
- 유통기한 수정 시 PK 변경 필요 (No!)
- 조인, 인덱싱 성능 저하
- 외래키 설정 시 관리 복잡성 증가
2. Auto Increment PK + 조합 바코드 (제품+창고+유통기한 코드)
장점
- DB 정규화 원칙에 부합한다. PK가 의미 없는 숫자 -> 다른 컬럼이 변경되어도 기본키는 변하지 않는다.
- 변경에 유연: 유통기한이나 제품코드 변경 시, 바코드만 바꾸면 되고 PK에는 영향이 없다.
- 성능 우수: 인덱싱, 조인 FK 참조 시 성능적으로 유리 (숫자 PK)
단점
- 재고 테이블을 직접 볼 때 의미를 직관적으로 파악하기 어렵다.
- 제품+창고+유통기합 조합이 중복되지 않도록 Unique 제약 조건을 따로 걸어야 한다.
결론 => 조회, 수정 성능 + 변경 유연성 -> Auto Increment PK + 유통기한 컬럼 생성
