[Chore] 주요 테이블 FK 제약조건 및 DB 마이그레이션 추가

[Hanharam]

배경

현재 여러 테이블이 다른 도메인의 식별자를 Long 값으로 저장하고 있지만, DB FK가 없어 존재하지 않는 사용자·게시글 ID나 고아 데이터가 저장될 수 있습니다.

JPA 엔티티 간에는 ID 참조 방식을 유지하면서, DB에서는 FK를 통해 데이터 무결성을 보장합니다.

작업 범위

인증

• social_accounts.user_id → users.user_id
• refresh_token_sessions.user_id → users.user_id

프롬프트

• posts.user_id → users.user_id

커뮤니티·신고

• comments.post_id → posts.post_id
• comments.user_id → users.user_id
• comments.parent_comment_id → comments.comment_id
• post_interactions.user_id → users.user_id
• post_interactions.post_id → posts.post_id
• post_reports.reporter_id → users.user_id
• post_reports.post_id → posts.post_id

결제·포인트

• post_unlocks.post_id → posts.post_id
• post_unlocks.user_id → users.user_id
• post_unlocks.creator_user_id → users.user_id
• point_histories.user_id → users.user_id

기존 FK 확인 대상

아래 관계는 JPA 연관관계가 있으므로 실제 DB의 FK 존재 여부를 먼저 확인합니다.

• post_image.post_id → posts.post_id
• post_statistics.post_id → posts.post_id
• post_tags.post_id → posts.post_id
• post_tags.tag_id → tags.tag_id

제외 및 별도 검토

• event_logs.user_id: 로그 보존 정책에 따라 FK 미적용 또는 ON DELETE SET NULL 검토
• event_logs.target_id: 다형 참조이므로 일반 FK 적용 제외
• point_histories.reference_id: 다형 참조이므로 일반 FK 적용 제외

사전 점검

• 운영·개발 DB의 기존 FK 현황 확인
• FK 추가 전 고아 데이터 조회 및 정리
• FK 컬럼 인덱스 존재 여부 확인
• 사용자·게시글·댓글의 실제 삭제 정책 확인
• 기본 삭제 정책은 RESTRICT/NO ACTION을 우선 검토
• Flyway 또는 배포 파이프라인의 마이그레이션 실행 경로 확인

완료 조건

• FK 추가용 신규 DB 마이그레이션 작성
• 이미 적용된 기존 마이그레이션 파일은 수정하지 않음
• 기존 데이터가 마이그레이션을 통과함
• FK 위반 저장 테스트 추가
• 로컬·테스트 환경에서 마이그레이션 검증
• 로그인·댓글·신고·구매·포인트 흐름 회귀 테스트 통과