문제

미리 설계해둔 DB를 불러와 Django 백엔드를 짜던 중이었다.
django에서는 inspectdb를 지원하여 알아서 db를 inspect하여 모델 코드로 바꿔주는 기능이 있다. 그걸 이용해서 모델을 불러들였다.

DB를 배우다 보면 M:N 관계에서 위와 같이 관계를 나타내는 테이블을 만들어서 해소해주는데 나도 당연히 위와 같이 설계를 해줬다.

그런데 django가 이를 불러들이자 기본 키에 두 가지 속성이 있음을 받아들이지 못하고 알아서 한 개만 기본키로 잡아버리는 것이었다.

그런 채로 코드를 짜려고 하니 get() returned more than one 같은 에러들이 쏟아져 나왔다.

해결

관계 테이블(위 그림의 주문-상품 테이블)에 자동 증가하는 serial로 artificial key를 만들어주니 문제가 해결되었다.
사실 이건 M:N 관계라서 생긴 문제가 아니라 django에서 복합 속성 기본 키를 지원하지 않아 생기는 문제이니 복합속성 기본 키를 가지는 테이블을 django에서 사용할 때는 가급적으로 인조키를 만들어 줘야 함을 알게 되었다.

사실 생각해보면 거래가 발생했을 때 여러 속성으로 기본키를 잡는 것보다 따로 거래 아이디를 생성하는 것이 자연스러운 것 같기도 하다.

느낀점

이 문제의 발단부터 해결까지 느낀 것이 참 많다.

일단 첫 번째로 실제 데이터가 쓰이는 곳을 잘 모른 채 데이터를 설계하면 안된다는 점을 느꼈다. 데이터베이스 설계도 그렇고 데이터 분석도 그렇고 모두 현장이 중요한 것 같다.

두 번째로 이 문제가 나에게 오기 전에 해결할 수도 있었는데 의사소통이 부족했다는 생각이다. 사실 이 문제를 포함해서 백엔드 구현을 해결 못한 우리 팀플 백엔드가 그대로 잠수를 타버려서 내가 백엔드에 투입된 건데 탈주하기 전에 조금만 더 함께 의사소통을 했다면 문제도 해결되고 팀플 이타치의 탈주도 막을 수 있지 않았을까라는 생각이 든다. 취직해서 데이터를 관리한다면 꼭 데이터를 소비하는 곳과 의사소통을 잘 하도록 하자.