[DB] 게시글 - 파일 테이블 설계

게시글-파일 테이블을 설계하는 과정에 고민했던 부분이 많아 기록으로 남기게 되었습니다.

---

우선 설계를 하기 앞서, 요구사항에 대한 2개의 기본적인 전제를 밝힙니다.

 

1) 하나의 게시글에 여러 개의 파일을 등록할 수 있다.

- 일반적으로 요구되는 사항으로, 만약 하나의 파일만 등록하는 요구사항이라고 하더라도 이후에 쉽게 확장될 수 있는 요구사항입니다.

 

2) 하나의 파일 테이블로 파일들을 모두 관리한다.

- 구체적인 예시는 다음과 같습니다.
'자유 게시판, 비밀 게시판, 홍보 게시판 ...' , '공지사항, 일대일 문의' 와 같이 여러 게시판이 있는 경우가 있습니다.

각 게시판의 성격에 따라 스키마가 달라져 이를 각각의 게시판 테이블로 설계를 해야되는 경우가 있지만, 파일의 경우는 정의되는 스키마가 동일해 하나의 파일 테이블로 설계를 해도 충분합니다. 이러한 설계 관점을 반영하기 위해 추가하였습니다.

(N개의 게시글 테이블마다 이에 종속되는 파일 테이블을 만든다면, 테이블 설계는 정말 간단해진다.)

 

 

---

 

1. 테이블 설계

[1번 구조]

게시판 테이블

게시판 아이디(PK)

 

파일 테이블

파일 아이디(PK)

게시판 아이디(FK)

파일 경로

 

위 설계는 1) 요구사항을 충족시키지만,
파일 테이블이 특정 게시판테이블에 종속적이게 되면서 2) 요구사항을 충족시키지 못합니다.

 

 

---

 

[2번 구조]

게시판 테이블

게시판 아이디(PK)

파일 아이디(FK)

 

파일 테이블

파일 아이디(PK)

파일 경로

 

외래키를 게시판 테이블에서 가지고 있는 설계입니다. 여기서 첫 번째 설계에서의 파일 테이블이 가지는 종속성은 사라져 2) 요구사항은 충족시키지만, 반대로 '하나의 파일 아이디'만 가지게 됨으로써 게시글 1개에 대해 파일 1개만 가져올 수 있습니다. 즉, 1) 요구사항을 충족시키지 못합니다.

 

 

---

 

[3번 구조]

게시판 테이블

게시판 아이디(PK)

파일 아이디(FK)

 

파일 테이블

파일 아이디(PK)

파일 시퀀스(PK)

파일 경로

 

2번 구조에서 파일 테이블에 '파일 시퀀스'를 두면서 복합키로 관리를 하면 문제는 해결됩니다.

게시판에서 복합키 중 일부인 파일 아이디만 참조를 하고, 파일 아이디를 통해서 나머지 여러 파일들을 조회할 수 있습니다.

 

 

장점

- 중간 테이블 설계가 필요하지 않다.

- 파일 테이블에 `FILE_CATEGORY_CODE`를 추가함으로써, 어느 게시판의 파일인지 구분할 수 있다.

 

단점

- 파일 테이블에서 복합키 설계가 필요하다.

- 복합키의 일부를 Auto사용하는 DBMS에 따라 파일 시퀀스를 보장하기 위한 추가 로직이 필요할 수 있다.

   - MySQL, MariaDB: 시퀀스 값 조회 후 +1

   - Oracle, PostgreSQL: @GeneratedValue(strategy = GenerationType.SEQUENCE)

 

   - ULID 설계

 

 

cf. ULID (Universally Unique Lexicographically Sortable Identifier)

UUID와 비슷하지만 시간 기반의 정렬이 가능하도록 설계된 고유 식별자이다.

삽입 순서를 유지하면서, 유니크한 값을 만들 수 있다.

 

 

---

 

[4번 구조]

게시판 테이블

게시판 아이디(PK)

 

게시판-파일 테이블

게시판 아이디(PK, 논리상 FK, 물리적으로 FK 설계는 하지 못함)

게시판 종류(PK)

파일 아이디(FK)

 

파일 테이블

파일 아이디(PK)

파일 시퀀스(PK)

파일 경로

 

여러 게시판이 있을 경우,
게시판-파일 테이블의 게시판 아이디(논리상 FK)가 중복될 수 있어 게시판 종류를 컬럼을 추가해 복합키로 두어야 합니다.

 

 

장점

- 어느 게시판의 파일인지, 중간 테이블을 통해 구분할 수 있다.

 

단점

- 3번 동일하다.

 

---

 

2. 생각 💭

일반적인 설계 방식은 "게시판 : 파일 = 1 : 다" 관계로 파일 테이블에 FK를 두어 관리합니다.

하지만 글의 서두에서 언급했듯이, 파일 테이블이 특정 게시판 테이블에 종속되지 않도록 하기 위해 고민이 시작되었습니다.

 

그 결과 여러 테이블 구조를 도출했으며, 요구사항을 충족한 3, 4번 테이블 구조를 선정했습니다.

3번 구조는 중간 테이블 없이 직관적인 테이블 설계가 가능하고,

4번 구조는 중간 테이블을 활용해 각 게시판 파일 조회가 용이합니다.

 

현재 프로젝트에서는 특정 게시판 파일을 조회 시, 중간 테이블을 한 번 더 Join을 하는 것보다 컬럼을 통해 직접적으로 바로 조회가 가능한 3번 구조로 테이블을 설계했습니다!