현업에서 DB로 복합키를 사용하는 게 많은지, 아니면 비즈니스 로직에서 검증하는지 궁금합니다.

Question

제목 그대로 만약에예약 대기라는 테이블이 있을 경우상품에 대한 정보와 예약을 대기하는 회원에 대한 정보를 foreign key로 가지고 있을 때,일반적으로 상품에 동일한 사람이 여러 개의 웨이팅 정보를 남기면 안 되기 때문에테이블을 설계할 때예약대기 고유ID회원 고유 ID상품 고유 ID이렇게 회원 고유ID와 상품 고유 ID를 식별키로 하여금 위 3가지 값을 primary key로 두어 복합키로 둬야 할지아니면예약 대기 고유ID만 primary key로 두고나머지 회원 고유ID와 상품 고유ID는 단순히 비식별 관계인 foreign key로 두고,비즈니스 로직에서 DB에 처리하기 전에 검증을 수행하는 방식으로 처리할지어떤 방식을 현업에서는 주로 사용하는지 궁금합니다.예전에 인터넷에서 봤던 글 중에&#34;DB에서 오류가 날 경우 인지하기 힘들기 때문에, 보통은 비식별 관계로 많이 두고, 비즈니스 로직에서 검증을 수행합니다.&#34; 라는 글을 본 적이 있던 것 같아서 질문드립니다.

집킨 · Answer

유니크 제약 걸면 되죠

옥다방고양이 · Answer

✅️예약 대기 고유ID만 primary key로 두고, 나머지 회원 고유ID와 상품 고유ID는 단순히 비식별 관계인 foreign key로 두고, 비즈니스 로직에서 DB에 처리하기 전에 검증을 수행하는 방식으로 처리할지 >>>>> 보통 이방법으로 하고 있습니다.DB 검색하는거 의외로 빠릅니다.그래서, 현업에서는 대부분의 비지니스 로직을 DB로 처리하는 경향이 높습니다.

장독깨기 · Answer

예약 아이디는 예약을 할 때 마다 따는거잖아요.그럼, 회원이 같은 상품을 두번 예약 하더라도, 예약아이디 &#43; 회원 &#43; 상품은 늘 유일하잖아요.그러니까, 저 3개를 PK 로 두는건 의미가 없습니다.예약 아이디를 PK 로 두고 회원 &#43; 상품을 유니크 키로 두든지,회원 &#43; 상품을 PK 로 둬야 한 회원이 한 상품에 두번 예약할 수 없게 됩니다.그리고, 이건 데이터베이스 관점에서 제약 사항입니다. 중복 데이터를 허용하지 않겠다는거죠.검증을 두가지 방식으로 생각할 수 있습니다.첫째, 무조건 집어 넣습니다. 그럼 중복 오류가 발생하겠죠. 이걸 체크하면 됩니다.둘째, 집어 넣기 전에 중복이 있는지 조회 합니다. 보통 이렇게 할 겁니다.이렇든 저렇든 제약 사항(PK 또는 유니크키) 을 걸어둬야 합니다.중복을 조회한다 해서 제약 사항을 걸 필요 없다 이런 식으로 생각할 필요 없습니다.마지막으로, 저 상품이 이벤트성 1회용 상품인가요?그게 아니라면, 오늘 예약을 했다 하더라도 한달 후에 같은 상품을 또 예약할 수 있는게 아닐까요.그럼, 회원 &#43; 상품을 유니크하게 하면 안 되겠죠. 추가 정보를 유니크키에 포함해야 할 것 입니다.

현업에서 DB로 복합키를 사용하는 게 많은지, 아니면 비즈니스 로직에서 검증하는지 궁금합니다.

3개의 답변

Q&A 목록