SQLAlchemy
SQLAlchemy는 Core와 ORM으로 알려진 두 가지 다른 구성 요소로 구성됩니다.
코어 자체는 완전한 기능을 갖춘 SQL 추상화 툴킷이며, 다양한 DBAPI 구현 및 동작에 대한 부드러운 추상화 계층을 제공할 뿐만 아니라 생성적 파이썬 표현을 통해 SQL 언어를 표현할 수 있게 해준다. DDL 문을 내보내는 것은 물론 기존 스키마를 검사할 수 있는 스키마 표현 시스템과 데이터베이스 유형에 대한 파이썬 유형의 매핑을 허용하는 유형 시스템이 시스템을 완결시킨다.
Object Relational Mapper(ORM) 객체 관계 매퍼는 코어를 기반으로 하는 선택적 패키지이다. 대부분의 응용 프로그램은 SQL 표현식 시스템을 사용하여 데이터베이스 상호 작용을 간결하고 정확하게 제어합니다.
작업 단위 SQLAlchemy의 ORM(Object Relational Mapper)의 중앙 부분인 Unit Of Work 시스템은 대기 중인 삽입/업데이트/삭제 작업을 대기열로 구성하고 모든 작업을 한 번에 플러시합니다. 이를 달성하기 위해 큐에 있는 모든 수정된 항목의 위상적 “의존성 정렬”을 수행하고, 때때로 더 멀리 배치될 수 있는 중복 문을 함께 그룹화한다. 이를 통해 효율성과 트랜잭션 안전성을 극대화하고 교착 상태를 최소화할 수 있습니다. 파울러의 “Unit of Work” 패턴과 자바의 대표적인 객체 관계 매퍼인 Hibernate를 본떠서 만들어졌다.
함수 기반 쿼리 구성 함수 기반 쿼리 구성을 사용하면 파이썬 함수 및 표현식을 통해 SQL 절을 만들 수 있습니다. 가능한 모든 범위에는 부울 표현식, 연산자, 함수, 테이블 별칭, 선택 가능한 하위 쿼리, 삽입/업데이트/삭제 문장, 상관 업데이트, 선택 및 EXIST 절, UNION 절, 내부 및 외부 조인, 바인딩 매개 변수 및 표현식 내 리터럴 텍스트의 자유 혼합이 포함됩니다. 생성된 표현식은 수많은 벤더 데이터베이스 구현(예: Postgre)에 따라 컴파일할 수 있습니다.SQL 또는 Oracle)은 구현에서 제공하는 “방언”과 “컴파일러”의 조합에 의해 결정됩니다.
모듈식 및 확장 가능 SQLAlchemy의 다른 부분들은 나머지 부분들과 독립적으로 사용될 수 있다. 연결 풀링, SQL 문 컴파일, 트랜잭션 서비스와 같은 요소는 서로 독립적으로 사용할 수 있으며 다양한 플러그인 포인트를 통해 확장할 수도 있다. 통합 이벤트 시스템은 코어 문 실행, 스키마 생성 및 검사, 연결 풀 작업, 객체 관계 구성, 지속성 작업, 속성 변환 이벤트 및 트랜잭션 단계를 포함하여 50개 이상의 상호 작용 지점에서 사용자 지정 코드를 주입할 수 있도록 한다. 새로운 SQL 식 요소와 사용자 지정 데이터베이스 유형을 원활하게 구축하고 통합할 수 있습니다.
별도의 매핑 및 클래스 설계 ORM은 대부분의 다른 객체 관계 도구가 제공하는 것과 동일한 방식으로 사용자 정의 클래스를 매핑된 테이블 메타데이터에 따라 구성할 수 있는 선언적 구성 시스템을 표준화한다. 그러나 이 시스템은 완전히 선택적이며, 핵심적으로 ORM은 사용자 정의 클래스, 관련 테이블 메타데이터 및 둘의 매핑을 완전히 별개로 간주합니다. 매퍼() 함수를 사용하면 임의의 파이썬 클래스를 데이터베이스 테이블이나 뷰에 매핑할 수 있다. 매핑된 클래스는 또한 다양한 캐싱 시스템에서 사용할 수 있도록 직렬화(피클링) 기능을 유지합니다.
관련 개체 및 컬렉션의 신속한 로드 및 캐싱 ORM은 한 번 로드되면 개체 간의 컬렉션과 참조를 캐시하므로 각 액세스에 SQL을 내보낼 필요가 없습니다. 빠르게 로드 기능을 사용하면 컬렉션 및 참조로 연결된 개체의 전체 그래프를 몇 개 또는 한 개의 쿼리로 로드할 수 있으며, 기존 쿼리를 변경할 필요 없이 매핑 또는 쿼리별로 정확한 문 수까지 구성할 수 있습니다. SQLAlchemy에서는 ORM이 컬렉션의 모든 개체에 대해 개별 문을 내보내야 하는 “N+1” 문제는 과거의 문제이다.
복합(다열) 기본 키 SQLAlchemy에서 기본 키와 외부 키는 열 집합으로 표현됩니다. 진정한 복합 동작은 처음부터 구현됩니다. ORM은 ONUPDATE CASCADE와의 호환성을 포함하여 의미 있는 (비대리) 기본 키에 대한 산업적 강도 지원뿐만 아니라 “연관” 객체와 같은 다른 일반적인 복합 PK 패턴에 대한 명시적인 지원을 가지고 있다.
자체 참조 개체 매핑 자체 참조 매핑은 ORM에서 지원됩니다. 인접 목록 구조는 적절한 캐스케이드를 사용하여 생성, 저장 및 삭제할 수 있으며, 코드 오버헤드는 비자기 참조 구조를 초과하지 않는다. 깊이의 자기 참조 구조 로드는 일련의 조인이 있는 단일 문(즉, 조인 로드) 또는 각각이 고유한 깊이 수준(즉, 하위 쿼리 로드)에서 전체 레코드 집합을 로드하는 다중 문을 통해 재귀적으로 로드 컬렉션에 맞게 조정될 수 있다. 상호 의존적인 외부 키 쌍(즉, “다중 x”/”하나의 특정 x”)을 가진 테이블과의 지속성 또한 “업데이트 후” 기능을 사용하여 기본적으로 지원됩니다.
상속 매핑 단일 테이블, 콘크리트 테이블 및 조인 테이블 상속에 대한 명시적 지원을 사용할 수 있습니다. 세 가지 스타일 모두에 대해 다형성 로드(즉, 여러 하위 유형의 개체를 반환하는 쿼리)가 지원됩니다. 각각의 로딩은 다형성 결과 세트를 완전히 로딩하기 위해 하나의 라운드 트립만 사용되도록 최적화될 수 있다.
원시 SQL 문 매핑 SQLA의 객체 관계 쿼리 기능은 원시 SQL 문뿐만 아니라 일반 결과 집합을 수용할 수 있으며, 객체 인스턴스는 다른 ORM 작업과 동일한 방식으로 이러한 결과로부터 생성될 수 있다. 사용자 또는 DBA가 작성할 수 있는 하이퍼 최적화된 쿼리는 SQLAlchemy에서 실행할 수 있으며, 행 집합 내에서 예상되는 열을 반환하는 한 개체를 가져올 수 있습니다. 여러 종류의 객체를 나타내는 문도 사용할 수 있으며, 결과를 명명된 튜플로 수신하거나 종속 객체를 상위 객체의 컬렉션으로 라우팅할 수 있다.
지원되는 플랫폼 SQLAlchemy는 최신 3.x 버전을 통해 Python 2.5를 지원합니다. 지원되는 다른 플랫폼으로는 Jython과 Pypython과 Pypy가 있다.
지원되는 데이터베이스 SQLAlchemy에는 SQLite, Postgresql, MySQL, Oracle, MS-SQL, Firebird, Sybase 등의 방언이 포함되어 있으며 대부분 여러 DBAPI를 지원한다. 다른 방언들은 외부 프로젝트로 출판된다. 각 특정 데이터베이스를 사용하려면 해당 DB-API 2.0 구현(또는 사용 가능한 여러 데이터베이스 중 하나)이 필요합니다. 현재 DBAPI 지원 보기
Object-relational mapping(ORM)
객체-관계 매핑(ORM, O/RM, O/R 매핑 도구)은 객체 지향 프로그래밍 언어를 사용하여 유형 시스템 간에 데이터를 변환하는 프로그래밍 기술이다. 이것은 사실상 프로그래밍 언어 내에서 사용할 수 있는 “가상 객체 데이터베이스”를 만든다.
객체 지향 프로그래밍에서 데이터 관리 작업은 거의 항상 비스칼라 값인 객체에 작용한다. 예를 들어, 0개 이상의 전화 번호와 0개 이상의 주소와 함께 한 사람을 나타내는 주소록 항목을 생각해 보십시오. 이것은 항목이 구성하는 각 데이터 항목(개인의 이름, 전화 번호 목록, 주소 목록)을 저장하기 위한 속성/필드를 가진 “개인 개체”에 의해 객체 지향 구현으로 모델링될 수 있다. 전화 번호 목록 자체에는 “전화 번호 개체” 등이 포함됩니다. 각각의 주소록 항목은 프로그래밍 언어에 의해 단일 객체로 취급된다(예를 들어 객체에 대한 포인터를 포함하는 단일 변수에 의해 참조될 수 있다). 기본 전화 번호, 집 주소 등을 반환하는 방법과 같이 다양한 방법을 개체와 연결할 수 있습니다.
대조적으로 SQL과 같은 많은 인기 있는 데이터베이스 제품들은 객체 지향적이지 않으며 테이블 내에 구성된 정수와 문자열과 같은 스칼라 값만 저장하고 조작할 수 있다. 프로그래머는 객체 값을 데이터베이스에 저장하기 위한 단순한 값의 그룹으로 변환하거나(검색 시 다시 변환) 프로그램 내에서 단순한 스칼라 값만 사용해야 한다. 객체-관계 매핑은 첫 번째 접근법을 구현한다.[1]
문제의 핵심은 객체의 논리적 표현을 데이터베이스에 저장할 수 있는 원자화된 형태로 변환하는 동시에 객체의 속성과 관계를 보존하여 필요할 때 객체로 다시 로드할 수 있도록 하는 것이다. 이 저장 및 검색 기능이 구현되면 개체가 영구적이라고 합니다.[1]
기존 데이터 액세스 기술과의 비교
객체 지향 언어와 관계형 데이터베이스 간의 전통적인 교환 기술과 비교하여, ORM은 종종 작성해야 하는 코드의 양을 줄여준다.[2]
ORM 도구의 단점은 일반적으로 구현 코드에서 실제로 일어나고 있는 일을 모호하게 하는 높은 수준의 추상화에서 비롯된다. 또한, ORM 소프트웨어에 대한 과도한 의존도는 설계가 부실한 데이터베이스를 생산하는 주요 요인으로 언급되었다.[3]
객체 지향 데이터베이스
또 다른 접근법은 데이터 모델링에서 더 많은 유연성을 제공하는 네이티브 XML 데이터베이스와 같은 객체 지향 데이터베이스 관리 시스템(OUDBMS) 또는 문서 지향 데이터베이스를 사용하는 것이다. OODBMS는 객체 지향 값으로 작업하기 위해 특별히 설계된 데이터베이스입니다. OODBMS를 사용하면 데이터가 원래 객체 표현으로 저장되고 관계가 직접 표현되므로 조인 테이블/작업이 필요하지 않으므로 SQL 형식으로 데이터를 변환하거나 변환할 필요가 없습니다. 문서 지향 데이터베이스를 위한 ORM과 동등한 ODM을 객체-문서 매핑기(ODM)라고 한다.
문서 지향 데이터베이스는 또한 사용자가 객체를 테이블 행으로 “분할”해야 하는 것을 방지합니다. 이러한 시스템 중 다수는 데이터 세트를 검색하기 위해 XQuery 쿼리 언어를 지원한다.