ORM 및 불활성 메커니즘

그러면 일단 ORM이 뭔지 알아야 돼요.
전문화된 측면에서 볼 때 대상 관계 매핑(Object-Relation Mapping)이라는 것은 대상과 관계 데이터베이스에 존재하는 서로 일치하지 않는 현상을 해결하기 위한 기술이다.
그럼 구체적으로 ORM은 무엇일까요?(django에서 코드의 클래스에 따라 자동으로 데이터베이스를 생성하는 테이블은 --code first라고도 부른다) ORM:
 
ORM은 객체 중심 모델과 관계 모델 사이에 다리를 놓습니다.
대상과 데이터베이스 사이에 비치는 메타데이터를 통해 음성 컴파일러의 대상을 관계 데이터베이스에 자동으로 투명하게 영구화하고 데이터베이스에 대한 조작을 대상에 대한 조작으로 전환할 수 있다
 
지금까지 우리 프로그램이 데이터베이스와 관련된 조작을 설계할 때 우리는 일반적으로 이렇게 했다.
먼저 데이터베이스를 만들고 테이블 구조와 필드를 디자인하며 mysqldb와 같은 모듈을 사용하여 데이터베이스를 연결합니다.
데이터 액세스 계층 코드 작성
업무 논리층이 데이터 접근층을 호출하여 데이터베이스 조작을 실행하다
(3층 구조 상해)
쉽게 말하면 ORM은 실례 대상의 문법을 통해 관계형 데이터베이스 조작을 완성하는 기술로'대상-관계 매핑'(Object/Relational Mapping)의 약자이다.
ORM은 데이터베이스를 대상으로 비추었다.

데이터베이스 테이블(table)-->클래스(class)

레코드(record, 줄 데이터) --> 대상(object)

필드(field) --> 대상의 속성(attribute)

예를 들어 다음은 SQL 문 한 줄입니다.

SELECT id, first_name, last_name, phone, birth_date, sex FROM persons WHERE id = 10

프로그램이 SQL을 직접 실행하고 데이터베이스를 조작하는 방법은 다음과 같다.

res = db.execSql(sql); name = res[0]["FIRST_NAME"];

ORM으로 쓰는 방법은 다음과 같다.

p = Person.get(10); name = p.first_name;

 
요약하면 ORM은 다음과 같은 장점을 가지고 있다.

데이터 모델은 모두 한 곳에서 정의되어 있어 업데이트와 유지보수가 쉽고 코드를 다시 사용하는 데도 유리하다.

ORM은 기존의 도구가 있는데 많은 기능을 자동으로 완성할 수 있다. 예를 들어 데이터 소독, 예처리, 사무 등이다.

이것은 MVC 구조를 사용하도록 강요한다. ORM은 천연 모델이고 최종적으로 코드를 더욱 뚜렷하게 한다.

ORM 기반의 업무 코드는 비교적 간단하고 코드량이 적으며 의미성이 좋아서 이해하기 쉽다.

성능이 좋지 않은 SQL을 작성할 필요가 없습니다.

 
하지만 ORM은 두드러진 단점도 있다.

ORM 라이브러리는 경량급 도구가 아니기 때문에 많은 정력을 들여 공부하고 설치해야 한다.

복잡한 조회에 대해 ORM은 표현할 수 없거나 성능이 원래의 SQL보다 못하다.

ORM은 데이터베이스 층을 추상화하여 개발자가 밑바닥의 데이터베이스 조작을 이해할 수 없고 특수한 SQL을 맞춤형으로 만들 수 없다.

 
Django 불활성 메커니즘
이른바 타성 메커니즘:Publisher.objects.all () 또는.Filter () 등은 QuerySet (조회 결과 집합 대상) 을 되돌려줍니다. sql를 바로 실행하지 않고 QuerySet을 호출할 때만 실행합니다.
타성 메커니즘의 교체 가능
1
2
3 # objs=models.Book.objects. all () # [obj1,obj2,ob3...] #  for   obj  in   objs: # obj , sql #     print( "obj:" ,obj)
불활성 메커니즘의 절편 가능
1
2
3
4 # objs=models.Book.objects. all () # [obj1,obj2,ob3...] # print(objs[1]) # print(objs[1:4]) # print(objs[::-1])
불활성 메커니즘의 Django 캐시 문제
Django는 자신의 캐시가 있습니다. 만약 2차의obj 대상이 일치한다면 두 번째 검색 값은 캐시에서 직접 값을 가져옵니다.
만약 그 동안 데이터베이스의 내용이 변경되었다면, 값을 다시 조사해야 한다.그렇지 않으면 더러운 데이터가 생기기 쉽다.
첫 번째obj 대상을 직접 이용하여 업데이트 작업을 할 수 있으며 다음 for 순환 조회 때 데이터베이스 조회 작업을 다시 실행할 수 있으며 이때 캐시도 변경되었다.다시 수동으로 결과를 조회할 수도 있지만 이렇게 하는 것을 추천하지 않습니다. 왜냐하면 우리는 데이터가 언제 수정될지 모르기 때문입니다. 적절한 것은 Django가 데이터를 사용할 때 스스로 데이터 결과를 조회하는 것입니다.
 
만약 2차 작업 사이에 데이터가 수정되었다면 데이터베이스에서 다시 값을 찾아야 한다. 그렇지 않으면 Django는 캐시에서 데이터를 꺼내 마지막 조회 결과에 영향을 줄 것이다.