1. IMAGE 테이블 리팩토링
1차 설계 당시 DB는 이러했다.
하지만 짜놓고 보니, BACK_IMAGE가 너무 보기 좋지 않았다.
-
BACK_IMAGE 참조 끊기
FILE 내부에는 배경용과 업로드용, 두가지 파일이 있다.
이 둘은 용도가 다르므로, 사실상 분리하는게 맞다.
따라서 참조를 끊고, 새로 테이블을 생성하였다.
-
POST_IMAGE 삭제 및 병합
BACK_IMAGE이 참조를 끊어버리면, FILE은 POST만을 위한 테이블이 되버린다.
따라서 POST_IMAGE를 삭제하고, POST_FILE로 이름을 바꿨다.
-
BACK_IMAGE 속성들 정리
FILE에서 data_type 속성은 빼고 똑같이 구성해준다.
(각 카테고리가 같은 배경을 사용해도 괜찮기 때문에, 용도를 분류하는 속성은 넣지 않았다.)
그리고 참조 관계는 N:1로 맺어준다.
(1:N 관계로 잘못 생각했는데, 배경 하나를 여러 카테고리가 쓸 수 있으므로, N:1인게 맞다...ㅠㅜ)
이상의 내용을 다이어그램으로 그리면 다음과 같다.
나름 괜찮은 설계가 만들어진 것 같다 : )
2. 여전히 문제...
그럼에도 뭔가 비효율적으로 보이는 것은 역시...
카테고리 때문이다.
괜히 카테고리를 3개나 만들어서, 3연속 참조 관계가 생겨버렸다..
그리고 BACK_IMAGE도 관계가 4개씩이나 되진 않을 것이다.
카테고리를 줄이는 것이 유일한 답일 것 같은데, 이대로 돌아가긴 너무 아쉽다..
이 벽을 넘으면 뭔가 한층 더 성장을 할 것 느낌이랄까...
아무래도 좀더 고민을 해봐야 할 것 같다ㅠㅜ
다음 글에선 어떤 형태가 되든 DB 최종안을 들고 올 것 같다
그럼 그때까지 화이팅!
