안녕하세요. 게시판ERD 수정했는데 다시 봐주실 수 있을까요?

Question

계정등급은 글 수정,삭제를 &#34;관리자&#34;등급이 가능할 수 있게하려고 추가해봤습니다.어제 글을 올리고 조언을 듣고 몇시간동안 고민하고 파티션을 찾아보며 이해해봤는데계정등급과 카테고리을 이렇게 DB로 나누고 나중에 DB 인덱스가 많아졌을때DB를 수평분할또는 샤딩으로 나누면그 유저의 역할(사용자,권리자) 카테고리 목록에 따라 더많은 데이터를 넣을 수 있고데이터의 압축률도 높아진다.또 계정등급 같은경우에는 글 수정 삭제에만 필요한 db값이기 때문에 나눠놓고 필요할때만 읽어올 수 있는 장점이 있다.라고 이해했는데 맞을까요?

리브12 · Accepted Answer

유저에 계정등급을 fk로 묶는건 별로 좋지않습니다. 사용자 등급을 확인하기 위해 굳이 한단계 더 들어갈 필요가 없는게 이유입니다. 또, 사용자 등급이 몇개 안될꺼면 서버측에서 enum형태로 관리하는게 정석이고 성능면에서도 좋습니다.게시글과 추천글이 나뉘어져 있는데, 이유가 따로 있으신가요 ? 의도를 볼땐 추천글 테이블에 넣는 데이터는 수동으로 입력할때인거같아서 그렇습니다. 제가볼땐 게시글과 "좋아요" 또는 "추천"을 mapping해주는 테이블로 자동으로 관리 하는게 좋아보이거든요.이 부분은 위에 유저계정등급과 비슷하지 않냐 라는 의문이 생길 수가 있습니다. 하지만, 데이터가 쌓이게된다면, 위의 상황과 많이 다를껍니다.게시글 테이블의 댓글 갯수는 필요없는 column입니다. 댓글테이블을 innerjoin 후 count로 집계하면 되니까요.게시글 내용은 varchar보단 text가 좋습니다. 글자수를 5000자로 제한하는것도 좋긴하지만, 이부분은 백엔드 코드에서 다루는게 추후를 수정하기 더 편할껍니다.첨부파일의 경우 가능하다면 file-type도 같이 넣어주면 좋습니다. 또, 원본이름도 추후 백업이 필요할 수도 있기때문에 있으면 좋습니다.카테고리 테이블에 master-slave관계를 추가하는것을 고려해보는 것도 좋을꺼같습니다. 쇼핑몰 같은곳을 본다면 상의, 하의 가 나뉘고 그 하단에 한번 더 카테고리가 있는것 처럼 말이죠. 이렇게 구성했을때, 백엔드에서 카테고리의 데이터를 조회한다면, innerjoin으로 게시물도 같이 가져올 수 있기도하구요

jjfactory · Answer

댓글에 유저id 빠진듯용?댓글수 비정규화 하실거면 추천수도 하실 수 있을듯?게시글에 파일id가 있을 필요가 있을까요? 파일이 여러개면 어떻게 되나용?

장독깨기 · Answer

전체적으로 수정 잘 하셨네요. ㅎ추천글은 일반적으로 사용자는 특정 게시글에 대해 한 번만 추천할 수 있습니다.그니까, 지금 수정한 그대로 두시면 됩니다.윗 분이 말씀하신 바 하루에 한번 특정 게시글을 중복해서 추천할 수 있다고 가정하면,일자를 컬럼으로 추가하고 PK 에 포함시키면 되겠죠. 근데, 하루에 한 번씩 추천할 수 있는 게시판이 일반적으로 있는지 모르겠군요. ㅎ테이블을 분리할 때는 아이디 외에 추가적인 정보가 필요할 경우 분리 하는 것이 좋습니다.카테고리 같은 경우 게시판 이름을 기본적으로 사용할테구요,추가적으로 게시판의 특성을 포함 시킬 수도 있습니다.가령, 공지사항 같은 경우는 일반 사용자가 글을 작성할 수 없게 한다든지, ...근데, 등급은 활용할 정보가 없으니 굳이 별도로 분리할 필요가 없어 보입니다.게시글, 파일아이디,댓글 아이디는 auto increment 로 하면 편하게 처리할 수 있습니다.그리고, 파티션, 분할, 샤딩 이런 부분에 지금은 크게 고민할 필요가 없습니다.실제 데이터가 대용량으로 쌓이게 될 경우 상황에 따라 여러가지 고려할 요소가 많습니다.마지막으로, 테이블명, 컬럼명에 영문명이 없는데요, 영문명도 작성하시구요,메뉴에 DDL 문 생성하는 기능이 있습니다. 복사해서 테이블 생성하면 됩니다.

안녕하세요. 게시판ERD 수정했는데 다시 봐주실 수 있을까요?

3개의 답변

Q&A 목록