comment 채번을 사용해야 하는 이유에 대한 설명이 필요합니다.
104
4 asked
안녕하세요. 식별 vs 비셕별에 대한 db 설계 관련 내용 중에 영한님께서 일대다의 경우인 board 테이블(one)과 comment(many)에서 board 테이블의 id가 식별관계로 사용되는 경우 comment의 id는 채번을 따서 사용해야하고 시퀀스나 auto increment를 사용할 수 없다고 하셨는데 그 이유가 궁금합니다.
어쨋든 board 테이블의 id값은 row마다 존재하기에 각 comment row의 데이터가 어떤 board에 속하는지 그리고 순서도 asc 순으로 보장된다고 생각하는데요..
꼭 채번을 사용해서 만들어야한다고 설명해주신 이유가 무엇인지 궁금합니다.
더구나 max+1 같은 경우 comment의 id값이 중복될 여지도 있다고 생각하는데요..
설명해주시면 감사하겠습니다.
Answer 3
0
안녕하세요. 변현진님 🙂
AUTO_INCREMENT는 테이블 전체를 기준으로 1씩 순차적으로 증가하는 고유한 값을 만들어냅니다. 하지만 식별 관계인 (board_id, comment_no) 구조에서 우리가 기대하는 comment_no는 다음과 같이 동작해야 합니다.
1번 게시글의 댓글: (1, 1), (1, 2), (1, 3)
2번 게시글의 댓글: (2, 1), (2, 2)
즉, board_id가 달라지면 comment_no는 다시 1부터 시작해야 합니다.
따라서 AUTO_INCREMENT를 사용할 수 없습니다.
감사합니다.
0
안녕하세요, 인프런 AI 인턴입니다. 변현진님.
DB 설계에서 일대다 관계에서의 식별자 관리에 대해 궁금해하신 점 잘 이해하였습니다. 먼저, 식별 관계에서의 primary key 설계는 데이터 무결성을 보장하고, 데이터의 유일성을 유지하는데 중요한 역할을 합니다.
김영한 강사님이 언급하신 ‘채번’을 사용하는 이유는 다음과 같습니다:
데이터의 유일성 보장: 시퀀스나 auto increment는 데이터베이스 시스템에 의해 고유하게 관리되는데 비해, 수동으로
max+1을 사용하는 경우는 동일한 값을 동시에 생성하는 경쟁 상태가 발생할 수 있어 유일성이 보장되지 않을 수 있습니다. 이는 데이터의 일관성을 저해하는 요인이 됩니다.동시성 문제 회피:
max+1방식은 여러 클라이언트가 동시에 삽입 작업을 수행할 경우, 동일한 키 값을 생성할 가능성이 있습니다. 이는 동시성 문제를 발생시켜 데이터 무결성을 위협할 수 있습니다. 시퀀스 또는 auto increment는 이런 문제를 해결하기 위해 고안된 메커니즘입니다.독립적 확장 가능성: 각 테이블이 자신의 기본키를 독립적으로 유지하면, 데이터 구조가 변경되더라도 서로 간섭 없이 확장 가능하다는 장점이 있습니다. 이는 system 설계의 유연성을 높입니다.
성능 고려: 수동으로
max+1을 계속해서 계산하면 성능 저하가 발생할 수 있습니다. 특히 데이터량이 많아지면 이 방식은 비효율적이게 됩니다.
이에 대해 더 자세히 알고 싶으시면 이 링크에서 관련 토론을 참고하실 수 있습니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
BCNF 질문
0
49
2
연관 엔티티 네이밍 규칙
0
40
1
진짜 강의 듣는거 너무 고문
0
114
1
28강 sql 파일 어딨나여?
0
79
1
2NF의 엄밀한 정의
0
66
1
학습중인 수업자료를 받아볼 수 있을까요??
0
92
2
수업자료 pdf파일관련 건의 - 제목 링크위치 개선
0
79
2
서비스 운영 중 잘못된 테이블 설계 발견시 수정 시점에 대한 질문
1
96
2
실무적인 설계로 접근했을 때 제 2정규형 항상 만족?
0
71
1
슈퍼/서브 타입 joined 전략
0
64
2
created_at 관련 구현과 DB ENUM에 대해
0
64
1
M:N 관계의 연관 엔티티 설계 순서
0
67
2
데이터 역사성 훼손 문제
0
60
2
실무팁 - 등록자,수정자 컬럼 관리 관련 질문입니다.
0
78
1
구글이 이메일 변경을 허용하는 이유
0
117
1
order_item 테이블 (order_id, product_id) 유니크 제약조건 누락
0
97
2
BCNF 정규화에 대한 질문
0
117
2
주문, 결제 엔티티의 분류
1
113
1
실무에서의 복수 항목에 대한 관리 방법이 궁금합니다.
0
86
1
역할 및 발생 시점에 따른 엔티티 분류
0
82
1
대리키의 외부 노출에 대한 질문을 하고 싶습니다.
0
104
2
소프트 딜리트 정책에서 유니크 컬럼 중복 방지 전략
0
91
1
대리키 사용과 정규화
1
106
2
강의자료 까마귀발 잘못된거 아닌가요?
1
125
2

