장고 orm 모델 0:1 관계는 어떻게 설계하는게 좋을까요? 0 4 468

by 보보 [DB 모델링/설계] [2020.02.11 12:55:35]



이미지 추가 및 수정할 사항이 많아서 글을 재작성 했습니다.

생각해보니 1:N관계가 아니고 0:1관계네요.

아래 요약글만 읽어주셔도 됩니다~

django orm을 쓰고 있고 장황하고 긴 글이지만 배포 후 상용화를 목표로 하고 있는 서비스고 풀스택 개발은 처음이라 우여곡절이 많은 상황입니다.

1인개발자라 조언 얻을 곳도 많지 않아 구루비와서 질문 남기게 됐습니다.

많은 조언해주시면 감사드려요.

구체적인 모델의 예를 들자면 Content이라는 모델이 하나 있다고 가정하고,

Content와 0:1 관계가 있는 모델은 Cartoon, Video, Article 등의 다양한 모델이 존재한다고 가정구요.

컨텐츠의 종류 Cartoon, Video, Article에 따라 필요한 필드들이 다르고 해당 컨텐츠 종류는 작성자에 따라서 하나만 작성할지 세개 모두 작성할지 결정할 수 있게끔 설계 되어야 합니다.

그리고 Cartoon, Video, Article 각각의 테이블 안에서도 필드 내용이 비어있는 경우도 있어요.

1. 예를들면 Video의 경우 서비스에서 업로드하지 않고 외부 영상을 가져온다면 파일크기, 영상포맷 등의 필드가 입력되지 않도록 할겁니다. 이렇게 비어있을 수 있는 필드들도 테이블 생성시 같이 컬럼을 생성해줘야되나요?

2. 그리고 Content와 연관된 Cartoon, Video, Article 등의 모델을 각각 Content와 FK를 주고 모델을 만들려고 합니다. 그런 경우에 Content 생성 시점에 Cartoon, Video, Article 중 어떤 것을 사용자가 생성하려고 하는지 판단한 뒤 각각의 모델을 생성해주는 방법이 최선인가요?

3. 단순히 생각하기에는 FK로 Cartoon, Video, Article 정보를 따로 테이블로 나누면 정규화는 되겠지만 테이블 생성 및 조회시 여러개의 테이블에 접근해야되기 때문에 오버헤드가 있지 않을까 하는 생각이 들어서요~ 하나의 테이블로 묶는게 더 나은건가 싶기도하고 조언 부탁드립니다~

Content 와 외래키로 묶어질 모델은 Cartoon, Video, Article 외에도 더 늘어날 가능성이 있습니다. 그리고 모델 내부의 필드들도 늘어날 수도 있구요. 상용 서비스를 목표로 하고 있는거라 배포 후 고객 반응에 따라 수정이 들어갈 것 같습니다.

#####추가#### 아까 글을 썼었는데

보실때 타입은 신경쓰지마시구요..

정석적으로 하려면 Video에 fileinfo라는 테이블을 하나 만들어서 파일 타입과 파일 사이즈를 추가해줘야할 것 같은데 비디오 하나만이라면 이렇게 해도되겠지만 테이블마다 선택적으로 입력되는 정보들이 많아지면 어느 테이블에 넣을거냐도 문제될것 같고 항상 같이 입력되지 않는 정보들도 존재할 수 있을 가능성이 있어서 어느정도로 정규화를 해야할지 모르겠네요..ㅠㅠ

생각중인 테이블도 첨부합니다.

요약하면

1. 아래와 같은 상황에서 Content에 선택적으로 입력되는 Content 종류를 외래키로 두고 입력이 없는 경우 비워두도록 설계하는게 바람직한가요?

2. Video 정보 입력 시 file_type / file_size가 선택적으로 입력이 된다면

Fileinfo라는 테이블을 따로 빼고 외래키를 두는게 정석적인 건가요?

3. 그렇다면 추가로 선택적으로 입력되는 컬럼들이 많아졌을때 종류에 따라 테이블을 어느정도까지 생성하는게 바람직한지..

조언부탁드립니다.

 

by 보보 [2020.02.11 14:43:05]

생각해보니 1번은 Video / FileInfo에 외래키로 Content와 연결시 참조 가능하도록 하면되는거네요.

그럼 Video에 값 추가시 Content의 외래키를 통해 관계를 만들어주면되구요.

0:1관계가 아니라 1:1관계네요.

자꾸 수정하면 다음에 보실분들이 혼란스러우니 제목은 그대로 두겠습니다.

#####

근데 여기서 드는 의문은 얼마나 정규화를 해야되느냐 입니다.

Video 안에 Fileinfo에 해당하지 않는 다른 추가 가능한 값들이 있다면 그런것들도 데이터 입력이 안될 가능성이 있다면 항상 새로운 테이블로 빼놔야 하는게 맞는건가요?

그럼 정규화 대상이 끝도 없어서, 테이블이 굉장히 많이 늘어날듯해서요.


by 보보 [2020.02.11 15:43:45]

내용을 좀 더 다시 정리해서 올리도록 하겠습니다.

가장 쉬운 데이터베이스 설계라는 책을 참고하고 있는데 비슷한 내용이 나올 것 같아 해답이 나오면 질문 글을 다시 올리지 않고 제가 댓글로 답변을 달도록 하겠습니다.

그럼 글 읽어주신 분들께 감사드립니다.


by 보보 [2020.02.12 14:58:58]

테이블을 나누고 필드를 나눌때 "" 책을 참고하여 아래와 같이 작성합니다. 이것은 꼭 지켜주시는게 데이터 무결성에 도움이 됩니다.

데이터 무결성이 유지되지 않으면 의도치 않은 값이 들어가거나, 값이 없거나, 의도대로 데이터 manipulate가 어려워집니다.

이상적인 테이블

1. 단일 주제를 나타낸다.

2. 기본키를 가진다.

3. 다중 부분 또는 다중값 필드를 포함하지 않는다.

4. 계산된 필드들을 포함하지 않는다.
 - fullname = firstname + lastname

5. 불필요한 이중 필드들을 포함하지 않는다.
 - 다른 테이블에도 있는 값이 똑같이 들어가 있는 경우.

6. 단지 절대적으로 최소한의 중복 데이터만 포함한다.

 

이상적인 필드의 요소

1. 테이블 주제의 고유한 특성을 나타낸다.

2. 단지 하나의 값만 포함한다.

3. 더 작은 구성요소로 해체될 수 없다.

4. 계산되거나 연결된 값을 포함하지 않는다.

5. 전체 데이터베이스 구조 안에서 유일하다.

이걸 지킨다고 가정하면 FK로 모두 연결하는게 맞는 듯합니다.

선택적으로 들어올 수 있는 값들도 별도의 label을 두고 조건에 따라 테이블을 나눠두는게 좋을것 같다는 생각이 드네요.


by 보보 [2020.02.12 15:02:16]

글이 너무 장황해서 답변을 다들 못해주신듯한데,

책 읽으면서 느낀건 무결성이 우선이고 성능은 차후입니다.

최대한 쪼개세요.

컬럼 하나에 값이 2개 들어가거하면 정렬도 어려워지고,

같은 값이 여러 테이블에 있으면 업데이트때 무결성이 깨질 수도 있습니다.

꼭꼭 값이 같은것들은 FK로 연결하시고

중복된 데이터들도 테이블을 쪼개시고 FK로 연결하세요~

댓글등록
SQL문을 포맷에 맞게(깔끔하게) 등록하려면 code() 버튼을 클릭하여 작성 하시면 됩니다.
로그인 사용자만 댓글을 작성 할 수 있습니다. 로그인, 회원가입