간단한 게시판을 만드려고 하는데 테이블 구조 설계가 고민입니다.

Question

간단한 커뮤니티 게시판을 하나 만드려고 하고 있습니다.문제는, 검색해보니 다들 이런 식으로 만들더군요게시글 table -> 게시글번호(PK), 컨텐츠, 작성자번호(FK)댓글 table -> 댓글번호(PK), 컨텐츠, 작성자번호(FK), 게시글번호(FK)근데 이렇게 만들면 유저가 게시글을 조회할 때마다 댓글 table의 튜플을 하나하나 순회하면서 &#34;댓글table.게시글번호 &#61; 게시글table.게시글번호&#34; 인 것들을 뽑아와야 하지 않나요?이러면 시간 복잡도가 댓글의 개수 N 개만큼 올라갈 것 같은데요...커뮤니티 특성 상 &#34;읽기&#34; > &#34;생성,수정,삭제&#34; 일 것 같은데, 게시글 조회의 시간 복잡도를 O(N) 으로 올려버리는 게 맞나 싶습니다.그래서 어떻게 하면 좋을까 하다가 다음과 같은 구조를 생각해봤습니다.게시글 table -> 게시글번호(PK), 컨텐츠, 작성자번호(FK), 댓글번호들댓글 table -> 댓글번호(PK), 컨텐츠, 작성자번호(FK), 게시글번호(FK)게시글 table.댓글번호들 컬럼엔, 해당 게시글에 달린 여러 댓글들의 PK를 저장해놓습니다.유저가 게시글을 클릭하면, &#34;댓글번호들&#34; 칼럼에 저장된 PK들을 기반으로, 댓글들을 가져와서 출력하는 방식입니다. (PK로 조회할 땐 시간 복잡도가 O(logn) 아니면 O(1) 인 걸로 알고 있습니다.)-> 의문점: 이게 맞나? 싶습니다.게시글 table을 제 1 정규형조차도 아니고, 그냥 비정규 릴레이션으로 만들어버리는 셈이니까요.이렇게 만들면 댓글이 생성되거나 삭제될 때마다 무결성을 유지하기 위해 코드를 정말 잘 짜놓아야 할텐데, 이런 식으로 만드는 게 맞나 라는 의문이 떠나질 않습니다.OKKY 같은 대형 사이트는 이런 부분을 어떻게 처리했나 굉장히 궁금합니다...그냥 게시글 table을 비정규 릴레이션으로 만들어버리는 게 맞는 걸까요?아니면 그냥 게시글 조회할 때마다 O(N)을 감수하는 게 맞는 걸까요?그것도 아니면 제가 생각 못 한 방법이 존재하는 걸까요?긴 질문글 읽어주셔서 감사합니다.

3CH-O · Answer

보통 게시글 번호로 인덱싱 하지 않나요?

poniard · Answer

하시면 안되고요. 유사한 형태의 엔티티 관계들이 사용자 -> 주문, 학생 -> 수강 관계를 가지는 형태로 대부분의 실세계 현상을 모델링할 때 나오게 됩니다. 그래서 데이터 무결성, 중복 방지 등을 위해 1차 정규화 과정을 거치게 되는거고요. 이 단계를 건너뛰는 모델링은 아주 특별한 성능 요건, 비즈니스 요건이 아니라면 되도록 지양하시는게 맞습니다.댓글 테이블의 게시글번호가 조인 조건 컬럼이 되기 때문에. 인덱스를 걸어주도록 합니다. DBMS 구현에 따라 다르겠지만 시간복잡도는 O(1 * log(n)) 또는 O(1 * n) 이 될 것으로 보입니다. SQL 세계에서 O(n) 시간 복잡도는 감수할 정도! 라고 표현할 만큼 그렇게 나쁘지는 않습니다. 오히려 잘못된 관계, 조인, 적절하지 않은 인덱스 설계 등으로 풀스캔을 하거나 필요없는 테이블을 읽는다 등의 문제가 더 많이 발생합니다.빅데이터 시대가 오면서 nosql db의 모델링 기법에서 반정규화 또는 트리구조를 채택하는 경우가 있는데 일단 RDBMS 에 대한 이해가 충분히 되고 그 다음 단계를 생각하는 것이 어떨까 합니다.

간단한 게시판을 만드려고 하는데 테이블 구조 설계가 고민입니다.

2개의 답변

기술 목록