Two scoops of django 6장 - 장고에서 모델이용하기

• 앱 하나에 모델이 스무 개 이상 있다면 ⇒ 앱을 분리한다. (다섯 개를 넘지 않는게 좋다는 의견)
• 모델 상속
  • 종류
    • 추상화 기초 클래스: 오직 상속받아 생성된 모델들의 테이블만 생성됨
      • ⇒ 부모 클래스를 독립적으로 이용할 수 없음
    • 멀티테이블 상속: 부모와 자식 모델에 대해서도 모두 테이블이 생성됨 (OneToOneField가 부모와 자식간 적용)
      • 부모 자식 어디로든 쿼리를 날릴 수 있으나, 자식 테이블에 대한 각 쿼리에 대해 부모 테이블로부터의 조인이 필요하므로 상당한 부하 발생 ⇒ 권하지 않는다
    • 프락시 모델: 원래 모델에 대해서만 테이블 생성됨
      • 각기 다른 행동을 하는 모델들의 별칭을 가질 수 있으나, 모델의 필드를 변경할 수 없음
  • 어떻게 사용?
    • 모델 사이에 중복되는 내용이 최소일 때(한 두개 중복) ⇒ 그냥 모델들에 필드 추가
    • 중복된 필드가 혼란을 야기할 정도로 많음 → 공통 필드는 추상화 기초 모델로 이전
• 데이터 베이스 마이그레이션
  • 생성된 마이그레이션 코드를 실행하기 전에 생성된 코드를 한번 살펴보자. + sqlmigrate 명령을 통해 어떤 SQL문이 실행되는지도 확인하자
  • 자체적인 django.db.migrations 스타일로 이루어지지 않은 외부 앱에 대해 마이그레이션 처리할 때는 MIGRATION_MODULES 세팅을 이용
  • 생성되는 마이그레이션 개수에 연연치 말자
• 모델 디자인
  • 데이터 베이스 정규화로부터 시작하자. 이미 모델에 포함된 데이터들이 중복되어 다시 다른 모델에 포함되지 않도록 신경 써야 한다.
  • 언제 BinaryField를 사용할 것인가
    • 메시지팩 형식의 콘텐츠
    • 원본 센서 데이터
    • 압축된 데이터(base64로 인코딩된 데이터들의 형식)
    • ⇒ 파일을 직접 서비스하는 것은 금물 (데이터베이스의 읽기/쓰기 속도는 파일 시스템의 읽기/쓰기 속도보다 항상 느림 + 데이터베이스 백업에 드는 공간과시간이 증가 + 파일 자체 접근에 장고 레이어, db 레이어 둘 다 거쳐야 함)
  • 범용 관계 (generic relations: 한 테이블로부터 다른 테이블을 서로 제약 조건이 없는 외부 키로 바인딩하는 것) 피하기
    • ⇒ 모델 간의 인덱싱이 존재하지 않아 쿼리 속도에 손해를 가져옴
    • 다른 테이블에 존재하지 않는 레코드를 참조할 수 있는 데이터 충돌의 위험성이 존재