상태 값 ENUM과 상태 별도 테이블

0. ENUM 사용 선택

분석 결과, 상태 정보가 단순하고 변경 가능성이 낮았습니다. 주로 모임 수락 여부(수락, 거절, 차단)나 활동 상태(활동, 차단)와 같이 고정적인 값들이어서 추가 속성이나 복잡한 구조가 필요하지 않았습니다.

따라서 ENUM을 사용하는 방식이 더 효율적이라고 판단했습니다. 이를 통해 테이블 구조가 간단해졌고, 조인 없이도 빠른 조회가 가능해졌습니다. 또한 상태 정보가 고정적이므로 확장성이 중요한 요구 사항이 아니었기에 ENUM이 적합한 선택이었습니다.

같은 이유로 불리언 타입의 컬럼 또한 별도의 테이블을 생성하지 않고 테이블에 직접 추가해도 문제가 없을 것으로 예상했습니다.

하지만 상태 값을 직접 테이블에 표현할 경우, 상태 이름을 변경해야 할 때 모든 레코드를 개별적으로 업데이트해야 하며, 이 과정에서 오류가 발생하면 데이터 일관성이 깨질 수 있습니다. 이는 트랜잭션 처리가 따로 적용되지 않는다면 더 큰 문제가 될 수 있습니다.

결론적으로 상태 정보가 복잡해지거나, 새로운 상태가 자주 추가되는 시스템에서는 별도의 상태 테이블을 구성하는 방식이 더 적합할 수 있음을 염두에 두고, ENUM을 선택하는 이유와 한계를 명확하게 이해하고자 합니다.

---

1. ENUM을 사용하는 경우

ENUM은 상태 정보를 컬럼의 데이터 타입으로 직접 정의하여 관리하는 방식입니다.

1) 장점

• 간단한 구현: 상태 값을 컬럼에 직접 정의하므로 테이블 구조가 단순합니다.
• 빠른 성능: 조인이 필요 없으므로 조회 속도가 빠릅니다.
• 코드 가독성: 상태 값이 스키마에 명시되어 있어 이해하기 쉽습니다.

2) 단점

• 확장성 제한: 새로운 상태를 추가하거나 수정하려면 테이블 스키마를 변경해야 합니다.
• 배포 복잡성: 스키마 변경 시 데이터베이스 마이그레이션이 필요하며, 이는 운영 환경에서 부담이 됩니다.
• 데이터 일관성 위험: 상태 이름을 변경할 때 모든 레코드를 업데이트해야 하며, 중간에 오류가 발생하면 데이터 불일치가 발생할 수 있습니다.

3) 예시

매핑 테이블 (ENUM 사용)

사용자 ID	모임 ID	상태 이름 (ENUM)
1	10	‘활성’
2	10	‘활성’
3	11	‘활성’
4	12	‘비활성’

• 상태 이름 컬럼은 ENUM 타입으로 정의되어 있습니다.

상태 이름을 ‘활성’에서 ‘활동 중’으로 변경하려면:

(1) 테이블 스키마 변경 필요

   ALTER TABLE 매핑테이블 MODIFY COLUMN 상태이름 ENUM('활동 중', '비활성');

(2) 기존 데이터 업데이트 필요

   UPDATE 매핑테이블 SET 상태이름 = '활동 중' WHERE 상태이름 = '활성';

• 이 과정에서 일부 레코드가 누락되면 데이터 일관성이 깨질 수 있습니다.

2. 별도의 상태 테이블을 사용하는 경우

상태 정보를 별도의 테이블로 분리하고, 매핑 테이블에서 상태 ID를 참조하는 방식입니다.

1) 장점

• 확장성: 새로운 상태 추가 시 데이터만 수정하면 되며, 스키마 변경이 필요 없습니다.
• 데이터 일관성 유지: 상태 이름 변경 시 한 곳만 수정하면 되므로 데이터 불일치가 발생하지 않습니다.
• 유연성: 상태에 대한 추가 속성 관리가 용이합니다.
• 재사용성: 여러 테이블에서 동일한 상태 목록을 공유할 수 있습니다.

2) 단점

• 복잡한 쿼리: 상태 이름을 조회하려면 조인이 필요합니다.
• 성능 영향: 조인으로 인해 대량의 데이터를 처리할 때 성능이 저하될 수 있습니다.
• 초기 설정 부담: 별도의 테이블과 관계를 설정해야 합니다.

3) 예시

상태 테이블

상태 ID	상태 이름
1	‘활성’
2	‘비활성’

매핑 테이블

사용자 ID	모임 ID	상태 ID
1	10	1
2	10	1
3	11	1
4	12	2

상태 이름을 ‘활성’에서 ‘활동 중’으로 변경하려면:

• 상태 테이블의 해당 레코드만 수정하면 됩니다.

  UPDATE 상태테이블 SET 상태이름 = '활동 중' WHERE 상태ID = 1;
  

• 매핑 테이블은 수정할 필요가 없으며, 모든 조회에서 변경된 상태 이름이 반영됩니다.

3. ENUM vs 상태 테이블 선택 기준

1) ENUM이 적합한 경우

• 상태 값이 고정적이고 변경 가능성이 낮을 때
• 상태 값이 단순하고 추가 속성이 필요 없을 때
• 빠른 개발과 간단한 구조가 필요한 경우

2) 상태 테이블이 적합한 경우

• 상태 값이 자주 변경되거나 확장 가능성이 있을 때
• 상태에 추가적인 속성이 필요한 경우
• 데이터 일관성과 확장성이 중요한 시스템인 경우
• 여러 테이블에서 동일한 상태 목록을 공유해야 할 때

4. 결론

상태 값이 단순하고 변경 가능성이 낮아 ENUM을 사용하는 것이 적합하다고 판단되었습니다. 이를 통해 개발 효율성과 성능을 향상시킬 수 있었습니다.

하지만 향후 상태 정보가 복잡해지거나 변경이 빈번해진다면, 별도의 상태 테이블을 사용하는 것이 데이터 일관성과 확장성 측면에서 더 바람직합니다.

따라서, 현재는 ENUM을 사용하되 상태 관리의 복잡도가 증가하면 별도의 상태 테이블로 전환하는 방안도 고려해야 합니다.