comment 채번을 사용해야 하는 이유에 대한 설명이 필요합니다.
104
投稿した質問数 4
안녕하세요. 식별 vs 비셕별에 대한 db 설계 관련 내용 중에 영한님께서 일대다의 경우인 board 테이블(one)과 comment(many)에서 board 테이블의 id가 식별관계로 사용되는 경우 comment의 id는 채번을 따서 사용해야하고 시퀀스나 auto increment를 사용할 수 없다고 하셨는데 그 이유가 궁금합니다.
어쨋든 board 테이블의 id값은 row마다 존재하기에 각 comment row의 데이터가 어떤 board에 속하는지 그리고 순서도 asc 순으로 보장된다고 생각하는데요..
꼭 채번을 사용해서 만들어야한다고 설명해주신 이유가 무엇인지 궁금합니다.
더구나 max+1 같은 경우 comment의 id값이 중복될 여지도 있다고 생각하는데요..
설명해주시면 감사하겠습니다.
回答 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
92
1
대리키 사용과 정규화
1
106
2
강의자료 까마귀발 잘못된거 아닌가요?
1
125
2

