[Database]: RDBMS N:M 중계 테이블 정규화 및 ERD 스키마 정립

[devikae]

Package Scope

• Add to an existing package
• New package

Package name: backend

Overview

프로필 부가 정보(베이스 스키장, 라이딩 성향)의 다대다 관계를 RDBMS 정석대로 처리하기 위한 데이터베이스 스키마 및 ERD를 정립합니다.

Describe the solution you'd like

1. MySQL 8.0 JSON 컬럼 사용 고민과 한계

• MySQL 8.0에서 지원하는 JSON 타입 컬럼을 활용하는 방안을 검토함.
• 그러나 RDBMS의 본질인 중복 제거 및 FK 참조 무결성 철학에 위배되며, 향후 스키장 명칭 변경 등 데이터 수정 발생 시 전체 유저의 JSON 데이터를 훑어 마이그레이션해야 하는 치명적 공수가 존재함.

2. 최종 결정 전략

• RDBMS의 정밀함과 무결성에 충실하게 중계 테이블(member_resort, member_riding_style)을 이용한 1:N, N:1 정석 분리를 채택.
• JPA 복합키 사용으로 인한 개발 지옥을 피하기 위해 중계 테이블에는 단일 대리키 id (PK) + UNIQUE KEY 구조를 채택.
• 비회원 및 익명 작성 지원을 위한 member_id NULLABLE 처리, 비회원 비밀번호(anonymous_password BCrypt), 작성자 IP (writer_ip) 보관 반영.

Additional context

• 1차 MVP 대상 총 11개 엔티티(회원, 크루, 리조트, 라이딩스타일, 카테고리, 게시글, 이미지, 추천/비추천, 댓글) 스키마 반영.

[yyy9942]

1. 수많은 유저가 동시에 게시글에 추천을 누르거나 댓글을 작성할 때, 역정규화된 카운트 컬럼의 정합성이 깨지는 레이스 컨디션(Race Condition)이 발생할 수 있습니다. 이를 동시성 락(비관적/낙관적 락)이나 Redis 분산 락으로 어떻게 처리할 계획인가요?
2. UUID는 완전히 무작위적인 문자열이기 때문에, 외부 API 노출용 public_id로 조회를 자주 수행하면 인덱스 무작위 삽입으로 인해 DB 내부적으로 페이지 스플릿(Page Split) 정렬 부하가 발생할 수 있습니다. 이를 완화하기 위한 DB 인덱스 튜닝 전략은 무엇인가요?
3. 댓글과 대댓글을 계층형으로 깊이 있게 조회할 때 발생할 수 있는 N+1 쿼리 문제를 어떻게 극복할 것인가요? CTE(Common Table Expression) 재귀 쿼리나 계층형 아키텍처 설계를 활용할 예정인가요?

[devikae]

1. 수많은 유저가 동시에 추천을 누를 때 DB 원자적 쿼리나 비관적 락 방식을 사용하면 DB 메모리의 대기줄이 길어지며 커넥션 풀 고갈 위험이 있다고 생각해 DB 락을 잡는 방식이 아닌 Redis Write-Behind 패턴으로 처리하려 합니다.
2. 조회를 위해서 public_id 컬럼에 UNIQUE INDEX (세컨더리 인덱스)를 생성하고, 이 인덱스의 파편화를 극복하기 위해 UUID v7 (Time-ordered UUID)을 채택합니다.
3. 계층형 아키텍처 설계를 활용할 생각입니다, JPA 엔티티 객체를 거치지 않고 JPQL을 이용해 댓글을 쿼리 호출 1회로 가져와 서비스 레이어에서 파싱하려 합니다