레거시 프로젝트를 현대적 PK 설계 방식으로 변환하는 과정이 궁금... - 인프런

현대적 설계에서는 대리키 PK와 자연키 UNIQUE 제약조건으로 데이터베이스 설계하는 것이 합리적이고 안정적이라고 하셨는데요

아직 대부분 레거시 프로젝트는 자연키를 PK로 사용하거나, 일부 테이블은 대리키로 PK를 사용하지만 여전히 많은 테이블들은 해당 일부테이블의 PK를 FK를 사용하여 복합 PK로 생성하여 사용하는 경우가 많습니다.

이런 레거시 프로젝트들의 복합 PK를 대리키 PK로 변환한다고 하면 전체적인 데이터베이스 구조를 재 설계해야 하는것이 맞겠지만 만약 기존 운영중인 테이블 구조를 유지하면서 PK를 변환하게 된다면, 기존 운영중인 테이블에 대리키 PK를 생성 후 기존 사용중이던 복합 PK에 UNIQUE 설정을 추가해주는 방식으로 변환하면 큰 문제가없을까요? 아니면 비즈니스 상황에따라 추가 제약조건을 추가해야 할 것들이 있을까요?

안녕하세요, 인프런 AI 인턴입니다. 브로콜링님, 데이터베이스 설계에서 대리키를 사용하는 현대적 방법으로의 전환에 대한 질문을 주셨군요.

대리키(대체 키)를 기존의 복합키 대신 사용하는 과정은 실무에서 꽤 복잡할 수 있습니다. 다음은 고려해야 할 몇 가지 주요 사항입니다:

기존 테이블 구조 유지: 기존 테이블을 운영하면서 대리키를 추가하는 방법은 가능합니다. 하지만 이때 주의할 점은 기존 데이터를 어떻게 관리할 것인지 입니다. 기존의 복합키를 연관 관계에서 제거하고 새로운 대리키로 대체하려면 데이터 무결성에 신경 써야 합니다.
UNIQUE 제약 조건 추가: 복합 PK 대신 UNIQUE를 추가하여 기존의 자연 키의 유일성을 보장할 수 있습니다. 단, 이 과정에서 인덱스가 추가되어 성능에 영향을 줄 수 있음을 고려해야 합니다.
외래키(FK) 업데이트: 다른 테이블에서도 기존의 복합키를 참조하고 있다면, 이 부분도 모두 업데이트 해야 합니다. 해당 테이블들도 대리키를 참조하도록 변경해야 합니다.
비즈니스 로직 변경 가능성: 데이터베이스 레이어뿐만 아니라 애플리케이션 레이어에서도 이에 맞는 수정이 필요할 수 있습니다. 특정 비즈니스 로직이 기존의 PK에 강하게 의존하고 있다면 이를 고려한 설계를 해야 할 것입니다.
전환 과정 테스트: 무엇보다도 데이터베이스 전환 과정에서 충분한 테스트가 필요합니다. 데이터 손실이나 무결성 오류가 발생하지 않도록 주의해야 합니다.

이에 대한 다양한 사례가 이미 여러 절차를 통해 연구되고 있습니다. 비슷한 질문과 답변을 통해 더욱 구체적인 사례를 확인해 보시길 추천드립니다. 관련 질문에 대한 김영한 강사의 답변을 참고해 주세요: 테이블 설계 관련 문의 및 MongoDB JPA 관련

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

인프런 커뮤니티 질문&답변

레거시 프로젝트를 현대적 PK 설계 방식으로 변환하는 과정이 궁금합니다.