DB 설계 관련해서 피드백 부탁드립니다.

Question

포트폴리오를 만들기 위해 현재 DB 설계중입니다.구상 중인 사이트는 기사와 회원을 매칭시켜주는 플랫폼이고 erd는 위의 이미지와 같습니다.후기 게시판에는 댓글과 대댓글 작성이 가능하고 댓글을 추천할 수 있도록 기능을 구현할 예정입니다.블로그 검색도 하고 다른 erd도 찾아보면서 만들었지만 DB 설계에 대한 지식이 없어 제대로 만든 건지 모르겠어서 의견을 여쭙고 싶습니다.

집킨 · Answer

나이가 먹은건가 왤케 안보일까요

HJOW · Answer

하긴 요새는 다들 실선을 안쓰기는 하죠.(실선은 외래키 제약조건까지 빡세게 걸었을 때 나올 겁니다.)테이블마다 PK는 무조건 있는 게 좋습니다. 성능에도 제법 영향이 갑니다.제 아무리 컬럼 두개짜리여도 말이죠.그외에는, 테이블마다 아예 고유값을 하나씩 따로 따서 PK로 지정했네요.1:N 관계더라도 예외없이...이 방법도 흔히 쓰기는 해서 이렇게 하지 말라고는 안하겠습니다만1:N관계에서 1쪽이 상위, N쪽이 하위테이블이라고 칭하면하위테이블쪽 PK값은 상위테이블 데이터 갯수의 몇배만큼씩 훅훅 증가하게 될겁니다. 물론 그 후기 추천을 얼마나 많이 할 지에 따라 다르겠죠.물론 운영 후 먼 미래겠지만, PK 컬럼 오버플로우도 염두에 두는 게 좋습니다.보통 이걸 어떻게 피하냐면하위테이블쪽에서, 컬럼을 두개를 PK를 주면 됩니다. 하나는 상위테이블 PK컬럼, 다른 하나는 자기자신의 PK컬럼이를테면Before후기ID / 후기_추천ID1 / 11 / 21 / 32 / 42 / 53 / 6After후기ID / 후기_추천ID1 / 11 / 21 / 32 / 12 / 23 / 1이렇게, 두번째 PK컬럼은 효율적으로 활용할 수가 있죠.그리고 회원의 아이디를 그 자체를 PK로 지정해도 됐을 텐데요.그럼 DB가 고유값 여부도 대신 검사해줘. 프로그램 수준에서 따로 검사하는 로직 안넣어도 돼. 얼마나 좋을까요.제약조건 걸려서 예외 발생했을 때, 오류코드 따서 중복 걸린 게 맞으면, 화면에는 이쁘게 &#34;이 아이디 누가 이미 쓰고 있어요 다른거 쓰세요&#34; 라고 해주면 되죠.

DB 설계 관련해서 피드백 부탁드립니다.

2개의 답변

Q&A 목록