TIL#131 Django Model(1)

모델은 장고 프로젝트의 토대가 되는 부분이다. 성급하게 장고 모델을 작성하게 되면 나중에 자신에게 고통거리가 되어 돌아오게 되거나 최악의 경우 해결방안을 선택해야 하는 경우를 야기하거나 기존 데이터가 충돌할 수 있다😂

모델이 너무 많으면 앱을 나눈다

앱 하나에 모델이 20개 이상 있다면 앱이 너무 많은 일을 하고 있다는 말이다. 크기가 작은 앱으로 분리하는 것을 고려해 보아야 한다.

모델 상속에 주의하자

장고는 세가지 모델 상속 방법을 제공한다. 추상화 기초 클래스(abstract base class), 멀티테이블 상속(multi-table ingeritance), 프락시 모델(proxy model)이다.

추상화 기초 클래스

오직 상속받아 생성된 모델들의 테이블만 생성된다.

• 장점 : 추상화된 클래스에 공통적인 부분을 추려 놓음으로써 한 번만 타이핑을 하면 된다. 추가 테이블이 생성되지 않고 여러 테이블에 걸쳐 조인을 함으로써 발생하는 성능 저하도 없다.
• 단점 : 부모 클래스를 독립적으로 이용할 수 없다.

멀티테이블 상속

부모와 자식 모델에 대해서도 모두 테이블이 생성된다. OneToOneField는 부모와 자식간에 적용된다.

• 장점 : 각 모델에 대해 매칭되는 테이블이 생성된다. 따라서 부모 또는 자식 모델 어디로든지 쿼리를 할 수 있다. 부모 객체로부터 자식 객체를 호출하는 것이 가능하다. -> `parent.child``
• 단점 : 자식 테이블에 대한 각 쿼리에 대해 부모 테이블로의 조인이 필요하므로 이에 따른 상당한 부하가 발생한다. 보통 멀티테이블 상속을 이용하지 않기를 권한다.

프락시 모델

원래 모델에 대해서만 테이블이 생성된다.

• 장점 : 각기 다른 파이썬 작용을 하는 모델들의 별칭을 가질 수 있다.
• 단점 : 모델의 필드를 변경할 수 없다.

어떤 종류의 상속이 언제 이용될 수 있는가

• 모델 사이에서 중복되는 내용이 최소라고 한다면(오직 한 두개의 명확한 필드만이 여러개의 모델 사이에서 공유되는 경우), 모델의 상속 자체가 필요없어진다. 그냥 모델 두 곳에 필드를 추가하면 된다.
• 모델들 사이에 중복된 필드가 혼란을 야기하거나 의도하지 않은 실수를 유발할 정도로 많을 때, 대부분의 경우 공통 필드 부분이 추상화 기초모델로 이전될 수 있게 리팩토링 할 수 있다.
• 프락시 모델은 종종 편리하게 이용되지만 다른 두 가지 모델 상속 방식과는 다르게 작동한다는 점에 주의해야 한다.
• 멀티테이블 상속은 혼란과 상당한 부하를 일으키므로 반드시 피하도록 한다. 멀티테이블 상속을 이용하는 대신 모델들 사이에서 좀 더 명확하게 OneToOneField와 ForeignKeys를 이용하여 컨트롤 할 수 있다.

모델 상속해보기

모든 모델에서 created와 modified 타임스탬프 필드를 생성해 두는 것은 일반적이기 때문에 일일히 손으로 필드를 추가하기보다는 TimeStampedModel 을 만들어서 상속하는 방법으로 해결할 수 있다.

# core/models.py
from django.db import models

class TimeStampedModel(models.Model):
    created_datetime = models.DateTimeField(auto_now_add=True)
    modified_datetime = models.DateTimeField(auto_now=True)
    
    class Meta:
        abstract = True
        
# flavors/models.py
from django.db import models

from core.models import TimeStampedModel

class Flavor(TimeStampedModel):
    title = models.CharField(max_length=200)

abstract=True 를 선언함으로써 추상화 기초 클래스가 되어 장고에서 마이그레이션을 실행할 때 테이블이 생성되지 않는다.

Database Migrations

• 배포 전에 마이그레이션을 되돌릴(rollback) 수 있는지 확인한다. 완벽한 복구가 아닌 적정 수준까지 되돌리기도 불가능하다면 규모가 큰 프로젝트에서는 버그 트래킹이나 배포시 큰 문제가 될 수 있다.
• 테이블에 수백만 개의 데이터가 이미 존재한다면 운영 서버에서 실제로 마이그레이션을 실행하기 전에 스테이징 서버에서 비슷한 크기의 데이터에 대해 충분히 테스트해야 한다.