블로그 / CMS 플랫폼

이 스키마에 대하여

눈여겨볼 관계

posts → post_revisions

글은 현재, 리비전은 역사이고 revision_number 가 순서를 줍니다. editor_id 가 리비전에 있는 이유는 마지막으로 고친 사람이 대개 글쓴이가 아니기 때문입니다.

categories → categories

parent_id 로 트리가 됩니다. 글은 분류를 정확히 하나 갖는데, 그 점이 여기서 분류와 태그를 가릅니다.

posts ↔ tags (post_tags)

다대다이고, 이 연결 테이블에는 자기 id 가 없습니다 — 쌍이 곧 키입니다. 글은 분류 하나와 태그 여럿을 갖습니다.

comments → comments

parent_id 로 답글이 중첩됩니다. is_approved 가 댓글마다 있어서, 부모는 공개된 채 답글만 보류할 수 있습니다.

media → users

업로드는 올린 사람의 것이지 글에 매이지 않습니다. 같은 이미지를 여러 글에서 쓸 수 있고, 글을 지워도 사진이 따라 지워지지 않습니다.

설계 판단

자주 묻는 것

리비전에 왜 차이가 아니라 본문 전체를 담나요?

판본을 되돌리는 일이 되감기가 아니라 읽기여야 하기 때문입니다. 글은 저장 공간이 문제 될 만큼 크지 않고, 차이 사슬은 중간 하나가 깨지면 그 뒤가 전부 무너집니다.

댓글이 users 를 가리키게 해야 하나요?

댓글에 로그인이 필요하다면 그렇게 하세요. author_name·author_email 대신 user_id 를 두면 됩니다. 필요 없다면 필드로 두는 편이 한 번 쓰고 마는 사람을 위해 사용자 행을 만들어 내지 않습니다 — 로그인한 독자용으로 nullable user_id 를 더해 둘 다 가질 수도 있습니다.

post_tags 에 왜 id 컬럼이 없나요?

(post_id, tag_id) 쌍이 키이고, 이 관계에 대해 더 할 말이 없기 때문입니다. 대리 id 를 두면 어차피 유니크 제약을 걸지 않는 한 같은 태그가 한 글에 두 번 붙을 수 있습니다.

예약 발행은 어떻게 되나요?

status 를 예약으로 두고 published_at 을 미래로 둡니다. 시각이 되면 상태를 바꿔 줄 무언가가 필요하거나, 읽기 질의가 "published_at 이 과거" 를 조건으로 삼아야 합니다. 뒤쪽이 단순하고 작업이 필요 없습니다.

키-값 설정 테이블이 괜찮은 방법인가요?

사이트 옵션 몇 개라면 괜찮습니다 — 배포 없이 편집자가 바꿀 수 있습니다. 값에 타입이나 검증이나 관계가 필요해지는 순간 좋은 방법이 아니게 됩니다. 그때부터는 읽는 쪽마다 문자열을 파싱하고 서로 해석이 달라집니다.