깃허브 (GitHub)

이 스키마에 대하여

눈여겨볼 관계

repositories → users / organizations

owner_id 와 org_id 중 하나. 소유권 이전이 새 저장소가 아니라 이 행의 갱신이라, 스타와 이슈가 따라갑니다.

repositories → repositories

forked_from_id 는 자기참조입니다. 포크는 자기 스타와 이슈를 가진 독립된 저장소이면서 어디서 왔는지를 기억합니다.

pull_requests → pr_reviews

리뷰가 각자 state 를 가진 행이라, 한 PR 이 어떤 리뷰어에게는 승인이고 다른 리뷰어에게는 변경 요청인 상태가 동시에 가능합니다.

issues → labels (issue_labels)

라벨이 전역이 아니라 저장소별입니다. 두 프로젝트가 서로 다른 색의 'bug' 라벨을 갖고, 한쪽이 다른 쪽 이름을 바꿀 수 없습니다.

actions_workflows → actions_runs

워크플로는 정의, 런은 자기 status·conclusion·커밋을 가진 한 번의 실행입니다. 워크플로 파일을 지운다고 무엇을 했는지의 기록까지 사라지면 안 됩니다.

설계 판단

자주 묻는 것

이슈와 PR 을 왜 안 합치나요?

PR 에는 이슈에 없는 브랜치·병합 상태·리뷰가 있고, 이슈에는 PR 이 다르게 쓰는 마일스톤과 담당자가 있습니다. 합치면 컬럼 절반의 의미가 종류 플래그에 달린 넓은 테이블이 됩니다. 나눌 때 어려워지는 것은 공유 번호 순번 하나뿐입니다.

저장소별 이슈 번호는 어떻게 유일하게 유지하나요?

이 스키마가 해 주지 않습니다. number 가 repo_id 범위이므로 (repo_id, number) 유니크 제약이 필요하고, 다음 값을 이슈와 PR 이 함께 합의해서 발급해야 합니다 — 보통 저장소 행의 카운터를 같은 트랜잭션에서 올립니다.

이슈와 PR 의 댓글은 어디 있나요?

이 템플릿에는 없습니다. 넣으려면 댓글 테이블 하나가 둘을 가리키게 할지 — nullable 컬럼 둘, 저장소 소유자와 같은 모양 — 각각 따로 둘지 정해야 합니다. 어느 쪽이든 댓글은 똑같이 그려지므로 하나로 두는 편이 보통입니다.

branches 테이블을 빼도 되나요?

늘 Git 에 묻는다면 됩니다. 이 테이블은 브랜치와 헤드를 나열하는 일이 ref 조회 묶음이 아니라 질의가 되게 하려고 있습니다. 브랜치가 많은 저장소의 페이지에서 차이가 납니다. 푸시가 갱신하는 캐시로 보세요.

actions_runs 가 왜 커밋 id 대신 sha 를 저장하나요?

런이 커밋 행보다 오래 남을 수 있고, 무엇이 실행됐는지를 가리키는 것이 sha 이기 때문입니다. commits 를 가리키면 아직 색인되지 않은 커밋에 대한 실행을 기록할 수 없습니다.