[Project] 상태 코드 관리에 대한 고민과 해결

Enum을 통한 상태 코드 관리 vs DB를 통한 상태 코드 관리

1. Enum을 통한 상태 코드 관리

• 장점: 간단하고 직관적이고 코드 내에서 상태를 쉽게 참조
• 단점: 상태 코드의 변경 및 확장이 어렵고 데이터베이스 외부에서 관리하기 때문에 일관성 보장 어려움

2. DB를 통한 상태 코드 관리

• 장점: 상태 코드의 변경 및 확장 용이하고 데이터베이스 내에서 관리하여 일관성 유지함
• 단점: 초기 설정과 관리가 다소 복잡함

결론: 상태 코드의 변경 가능성이 높다고 생각하여 일관성을 보장하기 위해 DB를 통해 관리하는 방법을 선택

테이블 별로 상태 코드 테이블을 만들기 vs 공통 상태 코드 테이블을 만들기

1. 테이블 별로 상태 코드 테이블을 만들기 

• 장점: 각 테이블에 특화된 상태 코드를 관리하기 쉽고 의미가 명확함
• 단점: 상태 코드가 중복될 경우가 있고 여러 개로 관리해야 해서 복잡함

2. 공통 상태 코드 테이블을 만들기

• 장점: 상태 코드의 중복을 최소화와 변경 및 확장이 용이함
• 단점: 상태 코드의 의미가 모호할 수 있고 일부 테이블에서 사용하지 않은 상태코드가 포함됨

결론: 데이터의 일관성과 중복 없이 관리할 수 있는 공통 상태 코드 테이블을 선택

선택한 방식들의 장점 요약: 

• 유연성: 하나의 테이블에서 상태 코드를 관리함으로써 상태 코드의 변경 및 확장이 용이함
• 일관성: 상태 코드를 DB 내에서 관리하기 때문에 일관성을 유지함
• 무결성: 동일한 상태 코드를 여러 테이블에서 사용하더라도 중복 없이 관리하여 데이터의 무결성을 보장함

팀 선택: 상태 코드의 변경과 확장이 쉽고 일관성 있게 관리하기 위해 DB를 통해 상태 코드를 관리하는 방식으로 선택했습니다.

CREATE TABLE status_code_tbl (
    status_code CHAR(1) PRIMARY KEY COMMENT '상태 코드',
    status_code_full_name VARCHAR(50) NOT NULL COMMENT '상태 코드 풀네임',
    status_description VARCHAR(255) NOT NULL COMMENT '상태 설명',
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP COMMENT '생성 일시'
) COMMENT '상태 코드 테이블';

-- 초기 데이터 삽입
INSERT INTO status_code_tbl (status_code, status_code_full_name, status_description) VALUES
('R', 'Requested', '신청'),
('C', 'Completed', '완료'),
('X', 'Cancelled', '취소'),
('A', 'Available', '보유'),
('N', 'Not Available', '미보유'),
('L', 'Lost', '분실'),
('O', 'On Loan', '대출');

끝.