강의

멘토링

커뮤니티

Inflearn コミュニティ Q&A

parkhj0629262 のプロフィール画像
parkhj0629262

投稿した質問数

김영한의 실전 데이터베이스 - 설계 2편, 실무에서 반드시 마주치는 9가지 설계 패턴

정리

common_code_detail의 code 변경 가능성

作成

·

60

·

編集済み

1

안녕하세요 영한님. 강의 정말 잘 듣고 있습니다.

common_code_detail은 pk로 natural key(group_code, code) 를 사용하는 것이 정형화되어 있다고 하신 부분을 이해했습니다.

 

서비스를 운영하다 보면 code의 값을 수정할 경우가 생길 가능성이 있을 거 같은데요.

예를 들면, 다음과 같은 요구사항이 있을 거 같습니다.

group_code가 ORDER_STATUS 인 code에 대한 변경 요청.

  • SHIPPING 을 두가지 상태로 확장(SHIPPING_START, SHIPPING_COMPLETED)

  • 변경 전의 SHIPPING은 SHIPPING_COMPLETED로 취급한다.

 

설계 1편의 "pk는 immutable해야한다" 라는 3번째 규칙이 있었는데요.

공통 코드 테이블의 경우에는 3번째 규칙을 유연하게 적용해야하나? 하는 생각이 들었습니다.

공통 테이블은 natural key를 사용하니 어느정도 허용을 한다고 보면 될까요?
아니면, 기존 키는 삭제하지 않은 채로 그대로 두고 새로 만들어서 규칙을 지키는 방향으로 하시는지 궁금하네요.

 

실무에서 이런 케이스들은 어떻게 다루시는지 궁금합니다. 감사합니다.

sqlmysqldbms/rdbms소프트웨어-설계SQLD

回答 1

1

yh님의 프로필 이미지
yh
インストラクター

안녕하세요. 박호정님

공통 코드는 개발 생산성과 가독성을 위해 Natural Key를 사용하며, 불변성 원칙을 실무적으로 타협합니다.

코드가 변경(예: SHIPPING 분리)될 때는 PK를 직접 수정(UPDATE)하지 않습니다. 대신에 데이터를 마이그레이션 하는데요. 예를 들면 다음과 같습니다.

  1. 신규 생성: 새로운 코드(SHIPPING_START, SHIPPING_COMPLETED)를 만듭니다.

  2. 데이터 이관: 기존 데이터를 새 코드(SHIPPING_COMPLETED)로 업데이트합니다.

  3. 구 코드 폐기: 기존 코드(SHIPPING)는 사용 중지 처리합니다.

이렇게 하면 이론적인 제약을 피하면서 안전하게 데이터를 관리할 수 있습니다.

감사합니다.

parkhj0629262 のプロフィール画像
parkhj0629262

投稿した質問数

質問する