데이터베이스에서 쓰기 및 읽기 균형 조정

이전 기사 관계형 데이터베이스처럼 테이블과 필드가 아닌, 함수 기반으로 구축된 데이터베이스의 개념과 구현에 대해 설명했습니다. 이는 기존 접근 방식에 비해 이 접근 방식의 장점을 보여주는 많은 예를 제공했습니다. 많은 사람들이 그들의 주장이 충분히 설득력이 없다고 생각했습니다.

이 기사에서는 이 개념을 통해 운영 논리를 변경하지 않고도 데이터베이스 쓰기와 읽기의 균형을 빠르고 편리하게 유지할 수 있는 방법을 보여 드리겠습니다. 최신 상용 DBMS(특히 Oracle 및 Microsoft SQL Server)에서도 유사한 기능을 구현하려는 시도가 있었습니다. 기사 끝에서 나는 그들이 한 일을 가볍게 말하면 그다지 잘 풀리지 않았다는 것을 보여줄 것입니다.

기술

이전과 마찬가지로 이해를 돕기 위해 예를 들어 설명을 시작하겠습니다. 직원 수와 총 급여가 포함된 부서 목록을 반환하는 논리를 구현해야 한다고 가정해 보겠습니다.

기능적 데이터베이스에서는 다음과 같습니다:

CLASS Department ‘Отдел’;
name ‘Наименование’ = DATA STRING[100] (Department);

CLASS Employee ‘Сотрудник’;
department ‘Отдел’ = DATA Department (Employee);
salary ‘Зарплата’ =  DATA NUMERIC[10,2] (Employee);

countEmployees ‘Кол-во сотрудников’ (Department d) = 
    GROUP SUM 1 IF department(Employee e) = d;
salarySum ‘Суммарная зарплата’ (Department d) = 
    GROUP SUM salary(Employee e) IF department(e) = d;

SELECT name(Department d), countEmployees(d), salarySum(d);


모든 DBMS에서 이 쿼리를 실행하는 복잡성은 다음과 같습니다. O(직원수)이 계산을 위해서는 전체 직원 테이블을 스캔한 다음 부서별로 그룹화해야 하기 때문입니다. 또한 선택한 계획에 따라 약간의 (부서보다 직원 수가 더 많은 것으로 생각됩니다) 보충이 있을 것입니다. O(로그 직원 수) 또는 O(학과수) 그룹화 등을 위해.

실행 오버헤드는 DBMS마다 다를 수 있지만 복잡성은 어떤 식으로든 변하지 않습니다.

제안된 구현에서 기능적 DBMS는 부서에 필요한 값을 계산하는 하나의 하위 쿼리를 생성한 다음 부서 테이블과 JOIN을 만들어 이름을 얻습니다. 그러나 각 함수에 대해 선언할 때 특별한 MATERIALIZED 마커를 설정할 수 있습니다. 시스템은 각 기능에 대해 해당 필드를 자동으로 생성합니다. 함수 값을 변경하면 동일한 트랜잭션에서 필드 값도 변경됩니다. 이 기능에 액세스하면 사전 계산된 필드에 액세스됩니다.

특히, 함수에 MATERIALIZED를 설정한 경우 직원 수 и 급여 합계, 그러면 부서 목록이 포함된 테이블에 두 개의 필드가 추가되어 직원 수와 총 급여가 저장됩니다. 직원, 급여 또는 부서 소속이 변경될 때마다 시스템은 이러한 필드의 값을 자동으로 변경합니다. 위 쿼리는 이러한 필드에 직접 액세스하고 다음에서 실행됩니다. O(학과수).

제한 사항은 무엇입니까? 단 한 가지: 이러한 함수에는 해당 값이 정의되는 유한한 수의 입력 값이 있어야 합니다. 그렇지 않으면 무한한 수의 행을 가진 테이블이 있을 수 없기 때문에 모든 값을 저장하는 테이블을 만드는 것이 불가능합니다.

예 :

employeesCount ‘Количество сотрудников с зарплатой > N’ (Department d, NUMERIC[10,2] N) = 
    GROUP SUM salary(Employee e) IF department(e) = d AND salary(e) > N;


이 함수는 숫자 N의 무한한 수의 값에 대해 정의됩니다(예: 음수 값이 적합함). 따라서 MATERIALIZED를 넣을 수 없습니다. 따라서 이는 기술적 제한이 아니라 논리적 제한입니다(즉, 구현하지 못했기 때문이 아닙니다). 그렇지 않으면 제한이 없습니다. 그룹화, 정렬, AND 및 OR, PARTITION, 재귀 등을 사용할 수 있습니다.

예를 들어 이전 기사의 문제 2.2에서는 두 함수 모두에 MATERIALIZED를 넣을 수 있습니다.

bought 'Купил' (Customer c, Product p, INTEGER y) = 
    GROUP SUM sum(Detail d) IF 
        customer(order(d)) = c AND 
        product(d) = p AND 
        extractYear(date(order(d))) = y MATERIALIZED;
rating 'Рейтинг' (Customer c, Product p, INTEGER y) = 
    PARTITION SUM 1 ORDER DESC bought(c, p, y), p BY c, y MATERIALIZED;
SELECT contactName(Customer c), name(Product p) WHERE rating(c, p, 1997) < 3;


시스템 자체는 유형 키가 있는 하나의 테이블을 생성합니다. 빠른 , 프로덕트 и 정수, 여기에 두 개의 필드를 추가하고 변경 사항이 있으면 해당 필드 값을 업데이트합니다. 이러한 함수를 추가로 호출하면 계산되지 않고 해당 필드에서 값을 읽습니다.

예를 들어 이 메커니즘을 사용하면 쿼리에서 재귀(CTE)를 제거할 수 있습니다. 특히 하위/상위 관계를 사용하여 트리를 형성하는 그룹을 고려하십시오(각 그룹에는 상위에 대한 링크가 있음).

parent = DATA Group (Group);


기능적 데이터베이스에서는 재귀 논리를 다음과 같이 지정할 수 있습니다.

level (Group child, Group parent) = RECURSION 1l IF child IS Group AND parent == child
                                                             STEP 2l IF parent == parent($parent);
isParent (Group child, Group parent) = TRUE IF level(child, parent) MATERIALIZED;


기능 때문에 isParent MATERIALIZED로 표시되면 두 개의 키(그룹)가 있는 테이블이 생성됩니다. isParent 첫 번째 키가 두 번째 키의 하위인 경우에만 true입니다. 이 테이블의 항목 수는 그룹 수에 트리의 평균 깊이를 곱한 것과 같습니다. 예를 들어 특정 그룹의 자손 수를 계산해야 하는 경우 다음 함수를 사용할 수 있습니다.

childrenCount (Group g) = GROUP SUM 1 IF isParent(Group child, g);


SQL 쿼리에는 CTE가 없습니다. 대신 간단한 GROUP BY가 사용됩니다.

이 메커니즘을 사용하면 필요한 경우 데이터베이스를 쉽게 비정규화할 수도 있습니다.

CLASS Order 'Заказ';
date 'Дата' = DATA DATE (Order);

CLASS OrderDetail 'Строка заказа';
order 'Заказ' = DATA Order (OrderDetail);
date 'Дата' (OrderDetail d) = date(order(d)) MATERIALIZED INDEXED;


함수를 호출할 때 데이터 주문 라인의 경우 인덱스가 있는 필드는 주문 라인이 있는 테이블에서 읽혀집니다. 주문 날짜가 변경되면 시스템 자체에서 라인의 비정규화된 날짜를 자동으로 다시 계산합니다.

장점

이 전체 메커니즘은 무엇을 위한 것입니까? 기존 DBMS에서는 쿼리를 다시 작성하지 않고도 개발자나 DBA는 인덱스를 변경하고, 통계를 확인하고, 쿼리 플래너에게 실행 방법을 알려줄 수만 있습니다(힌트는 상용 DBMS에서만 사용할 수 있습니다). 아무리 노력해도 기사의 첫 번째 쿼리를 완료할 수 없습니다. O(학과수) 쿼리를 변경하거나 트리거를 추가하지 않고. 제안된 방식에서는 개발 단계에서 데이터 저장 구조와 사용할 집계에 대해 생각할 필요가 없습니다. 이 모든 것은 작동 중에 즉석에서 직접 쉽게 변경할 수 있습니다.

실제로는 다음과 같습니다. 어떤 사람들은 당면한 작업을 기반으로 직접 논리를 개발합니다. 그들은 알고리즘과 그 복잡성, 실행 계획, 조인 유형, 기타 기술 구성 요소를 이해하지 못합니다. 이 사람들은 개발자라기보다는 비즈니스 분석가에 가깝습니다. 그런 다음 이 모든 것이 테스트 또는 작동에 들어갑니다. 장기 실행 쿼리의 로깅을 활성화합니다. 긴 쿼리가 감지되면 다른 사람들(보다 기술적인 - 기본적으로 DBA)이 일부 중간 기능에서 MATERIALIZED를 활성화하기로 결정합니다. 이로 인해 기록 속도가 약간 느려집니다(트랜잭션에서 추가 필드를 업데이트해야 하기 때문). 그러나 이 쿼리뿐만 아니라 이 기능을 사용하는 다른 모든 쿼리의 속도도 크게 향상됩니다. 동시에 어떤 기능을 구현할지 결정하는 것은 상대적으로 쉽습니다. 두 가지 주요 매개변수: 가능한 입력 값의 수(해당 테이블에 포함될 레코드 수)와 다른 기능에서 사용되는 빈도입니다.

아날로그

최신 상용 DBMS에는 FAST REFRESH를 사용한 MATERIALIZED VIEW(Oracle) 및 INDEXED VIEW(Microsoft SQL Server)와 같은 유사한 메커니즘이 있습니다. PostgreSQL에서는 MATERIALIZED VIEW를 트랜잭션에서 업데이트할 수 없고 요청 시에만(심지어 매우 엄격한 제한 사항이 있는 경우에도) 업데이트할 수 있으므로 고려하지 않습니다. 그러나 사용을 크게 제한하는 몇 가지 문제가 있습니다.

첫째, 이미 일반 VIEW를 생성한 경우에만 구체화를 활성화할 수 있습니다. 그렇지 않으면 이 구체화를 사용하기 위해 새로 생성된 뷰에 액세스하기 위한 나머지 요청을 다시 작성해야 합니다. 또는 모든 것을 그대로 두십시오. 그러나 이미 미리 계산된 특정 데이터가 있는 경우 적어도 비효율적이지만 많은 쿼리가 항상 이를 사용하지 않고 다시 계산합니다.

둘째, 엄청난 수의 제한 사항이 있습니다.

신탁

5.3.8.4 빠른 새로 고침에 대한 일반 제한 사항

구체화된 뷰의 정의 쿼리는 다음과 같이 제한됩니다.

• 구체화된 뷰에는 다음과 같이 반복되지 않는 표현식에 대한 참조가 포함되어서는 안 됩니다. SYSDATE 과 ROWNUM.
• 구체화된 뷰에는 다음에 대한 참조가 포함되어서는 안 됩니다. RAW or LONG RAW 데이터 유형.
• 다음을 포함할 수 없습니다. SELECT 목록 하위 쿼리.
• 분석 함수(예: RANK)에의 SELECT 절.
• 다음이 있는 테이블을 참조할 수 없습니다. XMLIndex 인덱스가 정의되어 있습니다.
• 다음을 포함할 수 없습니다. MODEL 절.
• 다음을 포함할 수 없습니다. HAVING 하위 쿼리가 있는 절.
• 다음이 포함된 중첩 쿼리를 포함할 수 없습니다. ANY, ALL및 NOT EXISTS.
• 다음을 포함할 수 없습니다. [START WITH …] CONNECT BY 절.
• 서로 다른 사이트의 여러 세부 테이블을 포함할 수 없습니다.
• ON COMMIT 구체화된 뷰는 원격 세부 정보 테이블을 가질 수 없습니다.
• 중첩된 구체화된 뷰에는 조인 또는 집계가 있어야 합니다.
• 구체화된 조인 뷰 및 구체화된 집계 뷰 GROUP BY 절은 인덱스 구성 테이블에서 선택할 수 없습니다.

5.3.8.5 조인만 포함된 구체화된 뷰의 빠른 새로 고침에 대한 제한 사항

조인만 있고 집계는 없는 구체화된 뷰에 대한 쿼리를 정의하면 빠른 새로 고침에 대해 다음과 같은 제한 사항이 있습니다.

• «의 모든 제한 사항빠른 새로 고침에 대한 일반 제한 사항".
• 그들은 가질 수 없습니다 GROUP BY 조항 또는 집계.
• 모든 테이블의 Rowid FROM 목록이 SELECT 쿼리 목록입니다.
• 구체화된 뷰 로그는 모든 기본 테이블에 대한 rowid와 함께 존재해야 합니다. FROM 쿼리 목록입니다.
• 객체 유형 열을 포함하는 단순 조인을 사용하면 여러 테이블에서 빠르게 새로 고칠 수 있는 구체화된 뷰를 생성할 수 없습니다. SELECT 성명서.

또한 다음과 같은 경우 선택한 새로 고침 방법이 최적으로 효율적이지 않습니다.

• 정의 쿼리는 내부 조인처럼 동작하는 외부 조인을 사용합니다. 정의 쿼리에 이러한 조인이 포함된 경우 내부 조인을 포함하도록 정의 쿼리를 다시 작성하는 것이 좋습니다.
• XNUMXD덴탈의 SELECT 구체화된 뷰 목록에는 여러 테이블의 열에 대한 표현식이 포함되어 있습니다.

5.3.8.6 집계가 포함된 구체화된 뷰의 빠른 새로 고침에 대한 제한 사항

집계 또는 조인을 사용하여 구체화된 뷰에 대한 쿼리를 정의하면 빠른 새로 고침에 대해 다음과 같은 제한 사항이 있습니다.

• «의 모든 제한 사항빠른 새로 고침에 대한 일반 제한 사항".

빠른 새로 고침은 두 가지 모두 지원됩니다. ON COMMIT 과 ON DEMAND 구체화된 뷰. 그러나 다음 제한 사항이 적용됩니다.

• 구체화된 뷰의 모든 테이블에는 구체화된 뷰 로그가 있어야 하며 구체화된 뷰 로그는 다음을 충족해야 합니다.
  • 구체화된 뷰에서 참조되는 테이블의 모든 열을 포함합니다.
  • 다음으로 지정 ROWID 과 INCLUDING NEW VALUES.
  • 지정 SEQUENCE 테이블에 삽입/직접 로드, 삭제 및 업데이트가 혼합되어 있을 것으로 예상되는 경우 절입니다.

• 만 SUM, COUNT, AVG, STDDEV, VARIANCE, MIN 과 MAX 빠른 새로 고침이 지원됩니다.
• COUNT(*) 지정해야 합니다.
• 집계 함수는 표현식의 가장 바깥쪽 부분으로만 발생해야 합니다. 즉, 다음과 같은 집계입니다. AVG(AVG(x)) or AVG(x)+ AVG(x) 허락되지 않는다.
• 다음과 같은 각 집계에 대해 AVG(expr), 해당 COUNT(expr) 존재해야 합니다. 오라클은 다음을 권장합니다. SUM(expr) 지정됩니다.
• If VARIANCE(expr) or STDDEV(expr)가 지정되었습니다. COUNT(expr) 과 SUM(expr) 지정해야 합니다. 오라클은 다음을 권장합니다. SUM(expr *expr) 지정됩니다.
• XNUMXD덴탈의 SELECT 정의 쿼리의 열은 여러 기본 테이블의 열이 포함된 복잡한 표현식일 수 없습니다. 이에 대한 가능한 해결 방법은 중첩된 구체화된 뷰를 사용하는 것입니다.
• XNUMXD덴탈의 SELECT 목록에는 모두 포함되어야 합니다. GROUP BY 열.
• 구체화된 뷰는 하나 이상의 원격 테이블을 기반으로 하지 않습니다.
• 당신이 CHAR 구체화된 뷰 로그의 필터 열에 있는 데이터 유형, 마스터 사이트와 구체화된 뷰의 문자 집합이 동일해야 합니다.
• 구체화된 뷰에 다음 중 하나가 있으면 빠른 새로 고침은 기존 DML 삽입 및 직접 로드에서만 지원됩니다.
  • 구체화된 뷰 MIN or MAX 집계
  • 구체화된 뷰 SUM(expr) 하지만 COUNT(expr)
  • 다음 없이 구체화된 뷰 COUNT(*)

  이러한 구체화된 뷰를 삽입 전용 구체화된 뷰라고 합니다.

• 구체화된 뷰 MAX or MIN 삭제 또는 혼합 DML 문이 없는 경우 빠르게 새로 고칠 수 있습니다. WHERE 절.
  삭제 또는 혼합 DML 후 최대/최소 빠른 새로 고침은 삽입 전용 경우와 동일한 동작을 갖지 않습니다. 영향을 받은 그룹의 최대/최소 값을 삭제하고 다시 계산합니다. 성능에 미치는 영향을 인식해야 합니다.
• 명명된 뷰 또는 하위 쿼리가 있는 구체화된 뷰 FROM 뷰를 완전히 병합할 수 있으면 절을 빠르게 새로 고칠 수 있습니다. 병합할 뷰에 대한 자세한 내용은 다음을 참조하세요. Oracle 데이터베이스 SQL 언어 참조.
• 외부 조인이 없으면 다음에서 임의 선택 및 조인이 있을 수 있습니다. WHERE 절.
• 외부 조인이 있는 구체화된 집계 뷰는 외부 테이블만 수정된 경우 기존 DML 및 직접 로드 후에 빠르게 새로 고칠 수 있습니다. 또한 내부 조인 테이블의 조인 열에는 고유 제약 조건이 존재해야 합니다. 외부 조인이 있는 경우 모든 조인은 다음으로 연결되어야 합니다. ANDs이며 등식을 사용해야 합니다(=) 운영자.
• 구체화된 뷰의 경우 CUBE, ROLLUP, 그룹화 집합 또는 이들을 연결하는 경우 다음 제한 사항이 적용됩니다.
  • XNUMXD덴탈의 SELECT 목록에는 다음 중 하나일 수 있는 그룹화 구분자가 포함되어야 합니다. GROUPING_ID 모두에 대한 기능 GROUP BY 표현이나 GROUPING 기능은 각각 하나씩 GROUP BY 표현. 예를 들어, GROUP BY 구체화된 뷰의 절은 "GROUP BY CUBE(a, b)" 그러면 SELECT 목록에는 "GROUPING_ID(a, b)" 또는 "GROUPING(a) AND GROUPING(b)» 구체화된 뷰를 빠르게 새로 고칠 수 있습니다.
  • GROUP BY 중복된 그룹화가 발생해서는 안 됩니다. 예를 들어, "GROUP BY a, ROLLUP(a, b)" 중복된 그룹화가 발생하므로 빠르게 새로 고칠 수 없습니다. "(a), (a, b), AND (a)".

5.3.8.7 UNION ALL을 사용한 구체화된 뷰의 빠른 새로 고침에 대한 제한 사항

구체화된 뷰 UNION ALL 집합 연산자 지원 REFRESH FAST 다음 조건이 만족되는 경우 옵션:

• 정의 쿼리에는 다음이 있어야 합니다. UNION ALL 최상위 수준의 연산자.

  XNUMXD덴탈의 UNION ALL 연산자는 한 가지 예외를 제외하고 하위 쿼리 안에 포함될 수 없습니다. UNION ALL 하위 쿼리에 있을 수 있습니다. FROM 절 정의 쿼리가 다음 형식인 경우 SELECT * FROM (보기 또는 하위 쿼리 UNION ALL) 다음 예와 같습니다.

  CREATE VIEW view_with_unionall AS (SELECT c.rowid crid, c.cust_id, 2 umarker FROM 고객 c WHERE c.cust_last_name = 'Smith' UNION ALL SELECT c.rowid crid, c.cust_id, 3 umarker FROM 고객 c WHERE c.cust_last_name = '존스'); 구체화된 뷰 생성 Unionall_inside_view_mv 요청 시 빠르게 새로 고침 * SELECT * FROM view_with_unionall;
  

  뷰는 참고하세요 view_with_unionall 빠른 새로 고침 요구 사항을 충족합니다.

• 각 쿼리 블록은 UNION ALL 쿼리는 집계가 있는 빠르게 새로 고칠 수 있는 구체화된 뷰 또는 조인이 있는 빠르게 새로 고칠 수 있는 구체화된 뷰의 요구 사항을 충족해야 합니다.

  해당 유형의 빠른 새로 고침이 가능한 구체화된 뷰에 필요한 적절한 구체화된 뷰 로그가 테이블에 생성되어야 합니다.
  Oracle 데이터베이스는 다음과 같은 경우에만 조인을 사용하여 단일 테이블 구체화된 뷰의 특별한 경우를 허용합니다. ROWID 열이 SELECT 목록 및 구체화된 뷰 로그에 있습니다. 이는 뷰의 정의 쿼리에 표시됩니다. view_with_unionall.

• XNUMXD덴탈의 SELECT 각 쿼리 목록에는 UNION ALL 마커, 그리고 UNION ALL 열에는 각 열에 고유한 상수 숫자 또는 문자열 값이 있어야 합니다. UNION ALL 나뭇가지. 또한 표식 열은 동일한 순서 위치에 나타나야 합니다. SELECT 각 쿼리 블록의 목록입니다. 보다 "UNION ALL 마커 및 쿼리 재작성»에 관한 자세한 내용은 UNION ALL 마커.
• 외부 조인, 삽입 전용 집계 구체화된 뷰 쿼리, 원격 테이블과 같은 일부 기능은 다음이 포함된 구체화된 뷰에 대해 지원되지 않습니다. UNION ALL. 그러나 조인이나 집계를 포함하지 않는 복제에 사용되는 구체화된 뷰는 다음과 같은 경우 빠르게 새로 고쳐질 수 있습니다. UNION ALL 또는 원격 테이블이 사용됩니다.
• 빠른 새로 고침이 가능한 구체화된 뷰를 생성하려면 호환성 초기화 매개변수를 9.2.0 이상으로 설정해야 합니다. UNION ALL.

나는 Oracle 팬을 화나게 하고 싶지 않지만 제한 사항 목록으로 판단하면 이 메커니즘은 일종의 모델을 사용하여 일반적인 경우가 아니라 모든 사람에게 다음과 같은 기회가 주어진 수천 명의 인도인에 의해 작성된 것 같습니다. 그들 자신의 브랜치를 작성했고, 그들 각자는 그가 할 수 있는 일을 했습니다. 실제 논리에 이 메커니즘을 사용하는 것은 지뢰밭을 걷는 것과 같습니다. 명확하지 않은 제한 사항 중 하나를 충족하면 언제든지 지뢰를 얻을 수 있습니다. 작동 방식 역시 별도의 질문이지만 이 기사의 범위를 벗어납니다.

마이크로 소프트 SQL 서버

추가 요구 사항

SET 옵션 및 결정적 기능 요구 사항 외에도 다음 요구 사항을 충족해야 합니다.

• 실행하는 사용자 CREATE INDEX 뷰의 소유자여야 합니다.
• 인덱스를 생성할 때, IGNORE_DUP_KEY 옵션은 OFF(기본 설정)로 설정되어야 합니다.
• 테이블은 두 부분으로 구성된 이름으로 참조되어야 합니다. 개요.테이블 이름 뷰 정의에서.
• 뷰에서 참조되는 사용자 정의 함수는 다음을 사용하여 생성되어야 합니다. WITH SCHEMABINDING 옵션을 선택합니다.
• 뷰에서 참조되는 모든 사용자 정의 함수는 두 부분으로 구성된 이름으로 참조되어야 합니다. ..
• 사용자 정의 함수의 데이터 액세스 속성은 다음과 같아야 합니다. NO SQL, 외부 액세스 속성은 다음과 같아야 합니다. NO.
• CLR(공용 언어 런타임) 함수는 뷰의 선택 목록에 나타날 수 있지만 클러스터형 인덱스 키 정의의 일부가 될 수는 없습니다. CLR 함수는 뷰의 WHERE 절이나 뷰에 있는 JOIN 작업의 ON 절에 나타날 수 없습니다.
• 뷰 정의에 사용되는 CLR 사용자 정의 유형의 CLR 함수 및 메서드에는 다음 표와 같이 속성이 설정되어 있어야 합니다.

  비즈니스 재산
  주의 사항

  결정적 = 참
  Microsoft .NET Framework 메서드의 특성으로 명시적으로 선언되어야 합니다.

  정확함 = 사실
  .NET Framework 메서드의 특성으로 명시적으로 선언되어야 합니다.

  데이터 액세스 = SQL 없음
  DataAccess 속성을 DataAccessKind.None으로 설정하고 SystemDataAccess 속성을 SystemDataAccessKind.None으로 설정하여 결정됩니다.

  외부 액세스 = 아니요
  CLR 루틴의 경우 이 속성의 기본값은 NO입니다.

• 뷰는 다음을 사용하여 생성되어야 합니다. WITH SCHEMABINDING 옵션을 선택합니다.
• 뷰는 뷰와 동일한 데이터베이스에 있는 기본 테이블만 참조해야 합니다. 뷰는 다른 뷰를 참조할 수 없습니다.
• 뷰 정의의 SELECT 문에는 다음 Transact-SQL 요소가 포함되어서는 안 됩니다.

  COUNT
  ROWSET 함수(OPENDATASOURCE, OPENQUERY, OPENROWSET, 그리고 OPENXML)
  OUTER 조인(LEFT, RIGHT및 FULL)

  파생 테이블(다음을 지정하여 정의됨) SELECT 성명서 FROM 절)
  자체 조인
  다음을 사용하여 열 지정 SELECT * or SELECT <table_name>.*

  DISTINCT
STDEV, STDEVP, VAR, VARP및 AVG
  공통 테이블 표현식(CTE)

  뜨다1, 본문, 텍스트, 영상, XML및 파일 스트림 열
  하위 쿼리
  OVER 순위 또는 집계 창 함수를 포함하는 절

  전체 텍스트 조건자(CONTAINS, FREETEXT)
  SUM Null 허용 표현식을 참조하는 함수
  ORDER BY

  CLR 사용자 정의 집계 함수
  TOP
CUBE, ROLLUP및 GROUPING SETS 운영자

  MIN, MAX
UNION, EXCEPT및 INTERSECT 운영자
  TABLESAMPLE

  테이블 변수
  OUTER APPLY or CROSS APPLY
PIVOT, UNPIVOT

  스파스 열 세트
  인라인(TVF) 또는 다중 문 테이블 반환 함수(MSTVF)
  OFFSET

  CHECKSUM_AGG

  1 인덱싱된 뷰에는 다음이 포함될 수 있습니다. 뜨다 기둥; 그러나 이러한 열은 클러스터형 인덱스 키에 포함될 수 없습니다.

• If GROUP BY 존재하는 경우 VIEW 정의에는 다음이 포함되어야 합니다. COUNT_BIG(*) 다음을 포함해서는 안 됩니다. HAVING. 이들 GROUP BY 제한 사항은 인덱싱된 뷰 정의에만 적용됩니다. 쿼리는 이러한 조건을 충족하지 않더라도 실행 계획에서 인덱싱된 뷰를 사용할 수 있습니다. GROUP BY 제한.
• 뷰 정의에 GROUP BY 절에 있는 고유 클러스터형 인덱스의 키는 해당 절에 지정된 열만 참조할 수 있습니다. GROUP BY 절.

여기서 인디언들은 "우리는 거의 하지 않지만 잘 할 것"이라는 계획에 따라 그것을 하기로 결정했기 때문에 관여하지 않았다는 것이 분명합니다. 즉, 현장에 더 많은 지뢰가 있지만 위치가 더 투명합니다. 가장 실망스러운 점은 다음과 같은 제한 사항입니다.

뷰는 뷰와 동일한 데이터베이스에 있는 기본 테이블만 참조해야 합니다. 뷰는 다른 뷰를 참조할 수 없습니다.

우리의 용어로 이는 함수가 다른 구체화된 함수에 액세스할 수 없음을 의미합니다. 이것은 싹의 모든 이데올로기를 잘라냅니다.
또한 이 제한 사항(및 본문에서 추가 설명)은 사용 사례를 크게 줄입니다.

뷰 정의의 SELECT 문에는 다음 Transact-SQL 요소가 포함되어서는 안 됩니다.

COUNT
ROWSET 함수(OPENDATASOURCE, OPENQUERY, OPENROWSET, 그리고 OPENXML)
OUTER 조인(LEFT, RIGHT및 FULL)

파생 테이블(다음을 지정하여 정의됨) SELECT 성명서 FROM 절)
자체 조인
다음을 사용하여 열 지정 SELECT * or SELECT <table_name>.*

DISTINCT
STDEV, STDEVP, VAR, VARP및 AVG
공통 테이블 표현식(CTE)

뜨다1, 본문, 텍스트, 영상, XML및 파일 스트림 열
하위 쿼리
OVER 순위 또는 집계 창 함수를 포함하는 절

전체 텍스트 조건자(CONTAINS, FREETEXT)
SUM Null 허용 표현식을 참조하는 함수
ORDER BY

CLR 사용자 정의 집계 함수
TOP
CUBE, ROLLUP및 GROUPING SETS 운영자

MIN, MAX
UNION, EXCEPT및 INTERSECT 운영자
TABLESAMPLE

테이블 변수
OUTER APPLY or CROSS APPLY
PIVOT, UNPIVOT

스파스 열 세트
인라인(TVF) 또는 다중 문 테이블 반환 함수(MSTVF)
OFFSET

CHECKSUM_AGG

OUTER JOINS, UNION, ORDER BY 등은 금지됩니다. 사용할 수 없는 것보다 사용할 수 있는 것을 지정하는 것이 더 쉬웠을 수도 있습니다. 목록은 아마도 훨씬 작을 것입니다.

요약하자면, LGPL 기술에서는 모든(상업용) DBMS와 없음(기술적이 아닌 논리적인 하나의 예외 제외)에 대한 엄청난 제한 사항이 있습니다. 그러나 관계형 논리에서 이 메커니즘을 구현하는 것은 설명된 기능 논리에서보다 다소 어렵다는 점에 유의해야 합니다.

Реализация

어떻게 작동하나요? PostgreSQL은 "가상 머신"으로 사용됩니다. 내부에는 쿼리를 작성하는 복잡한 알고리즘이 있습니다. 여기 출처. 그리고 많은 ifs가 포함된 대규모 휴리스틱 세트만 있는 것은 아닙니다. 따라서 몇 달 동안 공부할 시간이 있다면 건축을 이해하려고 노력할 수 있습니다.

효과적으로 작동합니까? 매우 효과적입니다. 불행하게도 이를 증명하는 것은 어렵습니다. 대규모 애플리케이션에 존재하는 수천 개의 요청을 고려하면 평균적으로 좋은 개발자의 요청보다 더 효과적이라고 말할 수 있습니다. 뛰어난 SQL 프로그래머는 어떤 쿼리든 더 효율적으로 작성할 수 있지만 수천 개의 쿼리를 사용하면 이를 수행할 동기나 시간이 없습니다. 이제 효율성의 증거로 언급할 수 있는 유일한 것은 이 DBMS를 기반으로 구축된 플랫폼에서 여러 프로젝트가 진행되고 있다는 것입니다. ERP 시스템는 수천 명의 서로 다른 MATERIALIZED 기능을 갖고 있으며, 수천 명의 사용자와 수억 개의 레코드가 일반 XNUMX프로세서 서버에서 실행되는 테라바이트 데이터베이스를 갖추고 있습니다. 그러나 다운로드를 통해 누구나 그 효과를 확인/반박할 수 있습니다. 플랫폼 그리고 포스트그레SQL, 켜 SQL 쿼리를 기록하고 거기에서 논리와 데이터를 변경하려고 합니다.

다음 기사에서는 기능 제한 설정, 변경 세션 작업 방법 등에 대해 설명합니다.

출처 : habr.com