원시 SQL을 여러 관련 Django 모델에 매핑하십시오.

Question

성능상의 이유로 장고의 ORM 쿼리 방법을 사용할 수 없기 때문에 일부 복잡한 질문에 원시 SQL을 사용해야합니다. SQL 쿼리의 결과를 여러 모델에 매핑하는 방법을 찾고 싶습니다.

다음 문을 사용하여 쿼리 결과를 하나의 모델에 매핑 할 수 있지만 관련 모델에 매핑 할 수있는 방법을 파악할 수는 없습니다 (예 : select_related 문을 사용하여 수행 할 수 있음). 장고).

model_instance = MyModel(**dict(zip(field_names, row_data))) 

쿼리 결과 집합에도있는 관련 테이블의 필드를 매핑하는 비교적 쉬운 방법이 있습니까?

Answer 1

먼저 ORM이 실적을 저해하고 있음을 증명할 수 있습니까? 때때로 성능 문제는 데이터베이스 설계가 부실하거나 인덱스가 부적절한 경우입니다. 보통 이것은 Django의 ORM을 레거시 데이터베이스 디자인에 강제 적용하려는 시도에서 비롯됩니다. 저장 프로 시저 및 트리거는 특히 트리거 코드가 Python 모델 코드에 포함될 것으로 예상되는 Django로 작업 할 때 성능에 나쁜 영향을 줄 수 있습니다.

때때로 성능 저하가 응용 프로그램 문제입니다. 여기에는 불필요한 주문 처리가 데이터베이스에서 수행됩니다.

가장 일반적인 성능 문제는 데이터를 "오버 페치"하는 응용 프로그램입니다. 부담없이 .all() 메서드를 사용하고 큰 메모리 내 컬렉션을 만듭니다. 이렇게하면 성능이 저하됩니다. Django 질의 세트는 질의 세트 iterator가 표시를 위해 템플릿에 주어 지도록 가능한 한 작게 만져야합니다.

일단 ORM을 우회하도록 선택하면 객체 - 관계 임피던스 불일치 문제를 해결해야합니다. 다시. 특히, 관계형 탐색에는 "관련"개념이 없습니다. 외래 키를 사용하여 관계형 집합을 일급으로 가져와야합니다. SQL을 통해 복잡한 메모리 내 객체 모델을 어셈블하는 것은 간단합니다. 순환 참조는이를 매우 어렵게 만듭니다. FK를 콜렉션으로 해석하는 것은 어렵습니다.

원시 SQL을 사용하려면 두 가지 옵션이 있습니다.

1. Eschew "선택 관련"- 존재하지 않으며 실행하기가 어렵습니다.

2. ORM과 유사한 "관련 항목 선택"기능을 발명하십시오. 일반적인 접근법은 (a) 개인 캐시를 검사하여 관련 객체를 가져 왔는지 여부와 객체가 존재하지 않는지 확인하고, (b) 데이터베이스에서 관련 객체를 가져 와서 캐시를 업데이트하는 상태 저장 getter를 추가하는 것입니다. 당신이 장고의 재발됩니다 자신의 상태 게터를 발명하는 과정에서

, 당신은 그것이 ORM 층하지만, 데이터베이스 디자인 또는 응용 프로그램 디자인 문제가되지 않는 것을 아마를 발견 할 것이다.