| PostgreSQL 8.3.3문서 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 35. 룰 시스템 | Fast Forward | Next |
INSERT, UPDATE, DELETE에 정의하는 룰은 전절에서 해설한 뷰의 룰과는 완전히 다릅니다. 첫째, 이러한 CREATE RULE명령에서는 이하를 실시할 수가 있습니다.
동작이 없는 룰도 가능합니다.
복수의 동작을 가질 수 있습니다.
INSTEAD 혹은 ALSO(기본값)을 취할 수가 있습니다.
유사 릴레이션NEW와 OLD가 유용해집니다.
룰 조건을 갖출 수 있습니다.
두 번째로, 그 곳에서 쿼리 트리를 변경하지 않습니다. 그 대신에 신규의 0개 이상의 쿼리 트리를 생성해, 원래의 것을 파기할 수가 있습니다.
구문이 계속됩니다.
CREATE [ OR REPLACE ] RULE
name
AS ON
event
TO
table
[ WHERE
condition
]
DO [ ALSO | INSTEAD ] { NOTHING |
command
| (
command
;
command
... ) }
상기의 구문을 기억해 주세요. 이하에서는, 갱신 룰은 INSERT, UPDATE, DELETE에 정의된 룰을 의미합니다.
갱신 룰은, 쿼리 트리의 결과 릴레이션과 명령 종류가 CREATE RULE로 주어지는 객체와 이벤트와 동일한 경우에 룰 시스템에 의해 적용됩니다. 갱신 룰에 대해서 룰 시스템은 쿼리 트리의 리스트를 생성합니다. 처음에 쿼리 트리 리스트는 비어있습니다. 0(NOTHING키워드), 1개 또는 복수의 동작이 유효합니다. 간단하게 하기 위해, 여기에서는 1개의 동작의 룰을 다룹니다. 이 룰은 조건을 가지고 있든 없든 상관하지않고, 또 INSTEAD나 ALSO(기본값)의 어느쪽이든 취할 수 있습니다.
룰 조건이란 어떤 것입니까. 그것은 룰의 동작을 실시하지 않으면 안 될 때와 해야할 때를 지정하는 조건입니다. 이 조건은, 기본적으로(특별한 이유를 가진) 객체로서 주어지는 릴레이션인 NEW유사 릴레이션이나 OLD유사 릴레이션, 또는, 그 양자만을 참조할 수 있습니다.
한 동작의 룰에 대해, 이하의 쿼리 트리를 생성하는 3개의 경우가 있습니다.
the query tree from the rule action with the original query tree's qualification added
본래의 문의 트리의 조건이 추가된, 룰 동작으로부터의 쿼리 트리
룰 조건과 본래의 쿼리 트리의 조건이 추가된, 룰 액션으로부터의 쿼리 트리
마지막으로, 룰이 ALSO의 경우, 변경되어 있지 않은 본래의 쿼리 트리를 리스트에 덧붙일 수 있습니다. 조건부의 INSTEAD룰만이 이미 본래의 쿼리 트리에 추가를 하고 있으므로, 1개의 동작을 가지는 룰에 대해서 1개 혹은 2개의 쿼리 트리에 가까스로 도착합니다.
ON INSERT룰에서는, 본래의 쿼리는, (INSTEAD에 의해 제지당하지 않은 한) 룰에 의해 추가된 동작의 전에 실행됩니다. 이것에 의해, 동작은 삽입된 행(복수가능)을 참조할 수가 있습니다. 그러나, ON UPDATE와 ON DELETE룰에서는, 본래의 쿼리는 룰에 의해 추가된 동작의 뒤에 실행됩니다. 이것은, 동작이 갱신될 예정의, 또는 삭제될 예정의 행을 참조할 수 있는 것을 보증합니다. 그렇지 않으면, 조건에 일치하는 행을 찾아낼 수가 없기 때문에, 동작이 작동하지 않게 될 가능성이 일어납니다.
룰 동작으로 생성된 쿼리 트리는, 재차 재작성 시스템에 건네져 상당수의 쿼리 트리의 결과를 가져오는, 보다 많은 룰의 적용을 받는 일도 있습니다. 그러니까, 룰의 동작은 룰 자신과는 다른 명령 종류나, 다른 결과 릴레이션을 가지고 있지 않으면 안됩니다. 그렇지 않으면, 이 반복적 처리에 의해 무한 루프에 빠져 버립니다. (룰의 반복 전개는 감지되어 에러로서 보고됩니다. )
pg_rewrite시스템 목록의 동작에 있는 쿼리 트리는 단순한 템플릿입니다. 이것들은 NEW와 OLD에 대한 범위 테이블의 항목을 참조할 수가 있기 때문에, 사용되기 전에 어떠한 치환 조치가 취해져야 합니다. NEW를 참조하는 모두에 대해, 본래의 쿼리의 대상 리스트는 대응하는 항목이 있는지 없는지 검색됩니다. 항목이 발견되었을 경우에는, 그 항목식이 참조를 옮겨놓습니다. 항목이 없었던 경우, NEW는 OLD와 같은 의미가 되거나(UPDATE의 경우), NULL에 의해 옮겨놓을 수 있습니다(INSERT의 경우). OLD에 대한 참조는 모두 결과 릴레이션인 범위 테이블의 항목에의 참조로 옮겨집니다.
갱신 룰의 적용이 끝나면, 시스템은 거기서 만들어진 쿼리 트리에 뷰 룰을 적용합니다. 뷰는, 새로운 갱신 동작을 삽입할 수 없기 때문에, 뷰 재작성의 결과에 갱신 룰을 적용할 필요는 없습니다.
shoelace_data릴레이션의 sl_avail열의 변화를 추적해 보고 싶다고 합시다. 로그용 테이블과 shoelace_data에 대해서 행해지는 UPDATE를 로그에 기록하는 룰을 준비했습니다.
CREATE TABLE shoelace_log (
sl_name text, -- 변경된 신발끈
sl_avail integer, -- 새로운 현재 가격
log_who text, -- 누가 했는지
log_when timestamp -- 언제 했는지
);
CREATE RULE log_shoelace AS ON UPDATE TO shoelace_data
WHERE NEW.sl_avail <> OLD.sl_avail
DO INSERT INTO shoelace_log VALUES (
NEW.sl_name,
NEW.sl_avail,
current_user,
current_timestamp
);
여기서 누군가가 이하를 실행합니다.
UPDATE shoelace_data SET sl_avail = 6 WHERE sl_name = 'sl7';
로그 테이블을 봅시다.
SELECT * FROM shoelace_log; sl_name | sl_avail | log_who | log_when ---------+----------+---------+---------------------------------- sl7 | 6 | Al | Tue Oct 20 16:14:45 1998 MET DST (1 row)
생각한 대로의 결과가 나왔습니다. 이하에 뒤에서 무엇이 일어났는지를 설명합니다. 파서가 우선 이하의 쿼리 트리를 생성했습니다.
UPDATE shoelace_data SET sl_avail = 6 FROM shoelace_data shoelace_data WHERE shoelace_data.sl_name = 'sl7';
이하의 룰 조건식
NEW.sl_avail <> OLD.sl_avail
및, 이하의 동작을 가지는 ON UPDATE의 log_shoelace룰이 있습니다.
INSERT INTO shoelace_log VALUES (
*NEW*.sl_name, *NEW*.sl_avail,
current_user, current_timestamp )
FROM shoelace_data *NEW*, shoelace_data *OLD*;
(통상, INSERT ... VALUES ... FROM를 쓸 수 없기 때문에 조금 이상하게 보일지도 모릅니다. 여기의 FROM구는 단지 *NEW*와 *OLD*의 쿼리 트리의 범위 테이블 항목이 있는 것을 나타내고 있을 뿐입니다. 이것들은, INSERT명령의 쿼리 트리중의 변수로부터 참조되기 위해서 필요합니다. )
이 룰은 조건부의 ALSO룰이므로, 룰 시스템은 변경된 룰 동작과 본래의 쿼리 트리라는 2개의 쿼리 트리를 돌려주지 않으면 안됩니다. 제1의 단계에서 본래의 쿼리의 범위 테이블은 룰 동작 쿼리 트리에 받아들여집니다. 그리고, 다음의 결과를 낳습니다.
INSERT INTO shoelace_log VALUES (
*NEW*.sl_name, *NEW*.sl_avail,
current_user, current_timestamp )
FROM shoelace_data *NEW*, shoelace_data *OLD*,
shoelace_data shoelace_data;
제2 단계에서, 이하와 같이 룰 조건을 덧붙일 수 있습니다. 이것에 의해, 이 결과 집합은 sl_avail가 변경한 행으로 한정됩니다.
INSERT INTO shoelace_log VALUES (
*NEW*.sl_name, *NEW*.sl_avail,
current_user, current_timestamp )
FROM shoelace_data *NEW*, shoelace_data *OLD*,
shoelace_data shoelace_data
WHERE *NEW*.sl_avail <> *OLD*.sl_avail;
(INSERT ... VALUES는 WHERE구를 가지지 않기 때문에, 이것은 더 이상합니다. 그러나, 플래너와 집행자에는 문제는 없습니다. 이것들은 어쨌든 INSERT ... SELECT를 위해서 같은 기능을 지원하지 않으면 안됩니다.)
제3 단계에서, 이하와 같이 본래의 쿼리 트리의 조건을 덧붙일 수 있어, 결과 집합은 본래의 쿼리로 변경된 행에만으로 한층 더 한정됩니다.
INSERT INTO shoelace_log VALUES (
*NEW*.sl_name, *NEW*.sl_avail,
current_user, current_timestamp )
FROM shoelace_data *NEW*, shoelace_data *OLD*,
shoelace_data shoelace_data
WHERE *NEW*.sl_avail <> *OLD*.sl_avail
AND shoelace_data.sl_name = 'sl7';
제4 단계에서는, 이하와 같이 본래의 쿼리 트리의 대상 리스트 항목, 또는 결과 릴레이션의 해당하는 변수 참조로, NEW의 참조를 치환합니다.
INSERT INTO shoelace_log VALUES (
shoelace_data.sl_name, 6,
current_user, current_timestamp )
FROM shoelace_data *NEW*, shoelace_data *OLD*,
shoelace_data shoelace_data
WHERE 6 <> *OLD*.sl_avail
AND shoelace_data.sl_name = 'sl7';
제5 단계는, 이하와 같이 OLD참조를 결과 릴레이션 참조에 옮겨놓습니다.
INSERT INTO shoelace_log VALUES (
shoelace_data.sl_name, 6,
current_user, current_timestamp )
FROM shoelace_data *NEW*, shoelace_data *OLD*,
shoelace_data shoelace_data
WHERE 6 <> shoelace_data.sl_avail
AND shoelace_data.sl_name = 'sl7';
이것이 마지막입니다. 이 룰은 ALSO이기 때문에, 본래의 쿼리 트리도 출력합니다. 정리하면, 룰 시스템으로부터의 출력은 이하의 문장에 대응하는 2개의 쿼리 트리의 리스트입니다.
INSERT INTO shoelace_log VALUES (
shoelace_data.sl_name, 6,
current_user, current_timestamp )
FROM shoelace_data
WHERE 6 <> shoelace_data.sl_avail
AND shoelace_data.sl_name = 'sl7';
UPDATE shoelace_data SET sl_avail = 6
WHERE sl_name = 'sl7';
이 두가지는 차례대로 처리되어 정확하게 룰이 정의한 대로입니다.
예를 들어 본래의 쿼리가 아래와 같은 경우에, 치환과 추가된 조건은, 로그에는 아무것도 쓰여지지 않는 것을 확실히 합니다.
UPDATE shoelace_data SET sl_color = 'green' WHERE sl_name = 'sl7';
이 경우, 본래의 쿼리 트리의 대상 리스트에는 sl_avail의 항목이 없기 때문에, NEW.sl_avail가 shoelace_data.sl_avail로 옮겨집니다. 그 결과, 이 룰에 의해 이하와 같은 특별한 쿼리가 생성됩니다.
INSERT INTO shoelace_log VALUES (
shoelace_data.sl_name, shoelace_data.sl_avail,
current_user, current_timestamp )
FROM shoelace_data
WHERE shoelace_data.sl_avail <> shoelace_data.sl_avail
AND shoelace_data.sl_name = 'sl7';
그리고 이 조건은 결코 실현되지 않습니다.
만약 본래의 쿼리가 복수의 행을 변경해도 잘됩니다. 따라서, 누군가가 아래와 같은 명령을 실행했다고 합니다.
UPDATE shoelace_data SET sl_avail = 0 WHERE sl_color = 'black';
이 경우, 실제로는 4행이 갱신됩니다(sl1, sl2, sl3 및 sl4). 그러나 s13는 이미 sl_avail = 0을 가지고 있습니다. 이 경우, 본래의 쿼리 트리의 조건을 채우지 않고, 그 결과, 이하와 같은 특별한 쿼리 트리가 룰에 의해 생성됩니다.
INSERT INTO shoelace_log
SELECT shoelace_data.sl_name, 0,
current_user, current_timestamp
FROM shoelace_data
WHERE 0 <> shoelace_data.sl_avail
AND shoelace_data.sl_color = 'black';
이 구문 분석 트리는 확실히 3개의 새로운 로그 항목을 삽입합니다. 이것은 완전히 올바른 동작입니다
여기서 본래의 쿼리 트리가 마지막에 실행되는 것이 중요한 이유를 알 수 있습니다. 만약 UPDATE가 먼저 실행되었다고 하면, 모든 행은 0에 세트 되어 0 <> shoelace_data.sl_avail인 행을 로그 기입시의 INSERT의 단계에서 찾아낼 수 없게 됩니다.
누군가가 뷰에 대해 INSERT, UPDATE, DELETE를 발행할 수 있다고, 거론된 가능성으로부터 뷰 릴레이션을 보호하는 간단한 방법은, 그러한 쿼리 트리를 파기해 버리는 것입니다. 이 때문에 이하의 룰을 만들 수가 있습니다.
CREATE RULE shoe_ins_protect AS ON INSERT TO shoe
DO INSTEAD NOTHING;
CREATE RULE shoe_upd_protect AS ON UPDATE TO shoe
DO INSTEAD NOTHING;
CREATE RULE shoe_del_protect AS ON DELETE TO shoe
DO INSTEAD NOTHING;
누군가가 shoe뷰 릴레이션에 상기의 조작을 실시하려고 하면, 룰 시스템은 룰을 적용합니다. 룰에는 동작이 없고, 한편, INSTEAD이기 때문에, 결과의 쿼리 트리 리스트는 비웁니다. 룰 시스템의 처리가 완료한 후에, 최적화되거나 실행되어야 할 것이 아무것도 남아 있지 않으므로, 쿼리 전체가 무효가 됩니다.
보다 적절한 룰 시스템의 사용법은, 실제 테이블에 적당한 조작을 실시하는 쿼리 트리에의 재작성을 실시하는 룰을 만드는 것입니다. shoelace뷰에 이것을 적용하기 위해서 이하의 룰을 만듭니다.
CREATE RULE shoelace_ins AS ON INSERT TO shoelace
DO INSTEAD
INSERT INTO shoelace_data VALUES (
NEW.sl_name,
NEW.sl_avail,
NEW.sl_color,
NEW.sl_len,
NEW.sl_unit
);
CREATE RULE shoelace_upd AS ON UPDATE TO shoelace
DO INSTEAD
UPDATE shoelace_data
SET sl_name = NEW.sl_name,
sl_avail = NEW.sl_avail,
sl_color = NEW.sl_color,
sl_len = NEW.sl_len,
sl_unit = NEW.sl_unit
WHERE sl_name = OLD.sl_name;
CREATE RULE shoelace_del AS ON DELETE TO shoelace
DO INSTEAD
DELETE FROM shoelace_data
WHERE sl_name = OLD.sl_name;
이 뷰상에서 RETURNING쿼리를 지원하고 싶은 경우, 뷰의 행을 계산하는 RETURNING구를 포함한 룰을 작성하지 않으면 안됩니다. 이것은 통상, 단일 테이블에 대한 뷰에서는 매우 간단합니다만, shoelace와 같은 뷰를 결합하는 경우는 다소 귀찮습니다. 삽입하는 경우를 예로서 이하에 나타냅니다.
CREATE RULE shoelace_ins AS ON INSERT TO shoelace
DO INSTEAD
INSERT INTO shoelace_data VALUES (
NEW.sl_name,
NEW.sl_avail,
NEW.sl_color,
NEW.sl_len,
NEW.sl_unit
)
RETURNING
shoelace_data.*,
(SELECT shoelace_data.sl_len * u.un_fact
FROM unit u WHERE shoelace_data.sl_unit = u.un_name);
이 1개의 룰이, 뷰에 대한 INSERT쿼리와 INSERT RETURNING쿼리 룰을 지원하는 것에 주의해 주세요. INSERT에서는 RETURNING구가 무시될 뿐입니다.
여기서 가게에는 부정기적으로 신발끈의 케이스가 두꺼운 운송장과 함께 도착된다고 가정합니다. 그러나, 매회 매회 수작업으로 shoelace뷰를 갱신하고 싶지는 않습니다. 대신에, 운송장으로부터 품목을 삽입하는 테이블과 특수한 장치를 가지는 테이블의 2개의 작은 테이블을 준비합니다. 이하는 그것들을 작성하는 명령입니다.
CREATE TABLE shoelace_arrive (
arr_name text,
arr_quant integer
);
CREATE TABLE shoelace_ok (
ok_name text,
ok_quant integer
);
CREATE RULE shoelace_ok_ins AS ON INSERT TO shoelace_ok
DO INSTEAD
UPDATE shoelace
SET sl_avail = sl_avail + NEW.ok_quant
WHERE sl_name = NEW.ok_name;
이것으로, 운송장의 데이터를 shoelace_arrive테이블에 투입할 수가 있습니다.
SELECT * FROM shoelace_arrive; arr_name | arr_quant ----------+----------- sl3 | 10 sl6 | 20 sl8 | 20 (3 rows)
그리고 현재의 데이터를 체크합니다.
SELECT * FROM shoelace; sl_name | sl_avail | sl_color | sl_len | sl_unit | sl_len_cm ----------+----------+----------+--------+---------+----------- sl1 | 5 | black | 80 | cm | 80 sl2 | 6 | black | 100 | cm | 100 sl7 | 6 | brown | 60 | cm | 60 sl3 | 0 | black | 35 | inch | 88.9 sl4 | 8 | black | 40 | inch | 101.6 sl8 | 1 | brown | 40 | inch | 101.6 sl5 | 4 | brown | 1 | m | 100 sl6 | 0 | brown | 0.9 | m | 90 (8 rows)
이제, 도창된 신발끈을 이동합니다.
INSERT INTO shoelace_ok SELECT * FROM shoelace_arrive;
그리고 결과를 확인합니다.
SELECT * FROM shoelace ORDER BY sl_name; sl_name | sl_avail | sl_color | sl_len | sl_unit | sl_len_cm ----------+----------+----------+--------+---------+----------- sl1 | 5 | black | 80 | cm | 80 sl2 | 6 | black | 100 | cm | 100 sl7 | 6 | brown | 60 | cm | 60 sl4 | 8 | black | 40 | inch | 101.6 sl3 | 10 | black | 35 | inch | 88.9 sl8 | 21 | brown | 40 | inch | 101.6 sl5 | 4 | brown | 1 | m | 100 sl6 | 20 | brown | 0.9 | m | 90 (8 rows) SELECT * FROM shoelace_log; sl_name | sl_avail | log_who| log_when ---------+----------+--------+---------------------------------- sl7 | 6 | Al | Tue Oct 20 19:14:45 1998 MET DST sl3 | 10 | Al | Tue Oct 20 19:25:16 1998 MET DST sl6 | 20 | Al | Tue Oct 20 19:25:16 1998 MET DST sl8 | 21 | Al | Tue Oct 20 19:25:16 1998 MET DST (4 rows)
1개의 INSERT ... SELECT로부터 이 결과가 되려면, 긴 과정이 있습니다. 본장에서의 쿼리 트리의 변형에 관한 설명은 이것이 마지막입니다. 우선, 이하와 같은 파서의 출력이 있습니다.
INSERT INTO shoelace_ok SELECT shoelace_arrive.arr_name, shoelace_arrive.arr_quant FROM shoelace_arrive shoelace_arrive, shoelace_ok shoelace_ok;
최초의 shoelace_ok_ins룰이 적용되어 결과는 이하와 같이 됩니다.
UPDATE shoelace
SET sl_avail = shoelace.sl_avail + shoelace_arrive.arr_quant
FROM shoelace_arrive shoelace_arrive, shoelace_ok shoelace_ok,
shoelace_ok *OLD*, shoelace_ok *NEW*,
shoelace shoelace
WHERE shoelace.sl_name = shoelace_arrive.arr_name;
그리고, shoelace_ok에 대한 본래의 INSERT를 파기합니다. 재작성된 쿼리는 다시 룰 시스템에게 건네져, 2번째에 적용되는 shoelace_upd룰은 이하를 생성합니다.
UPDATE shoelace_data
SET sl_name = shoelace.sl_name,
sl_avail = shoelace.sl_avail + shoelace_arrive.arr_quant,
sl_color = shoelace.sl_color,
sl_len = shoelace.sl_len,
sl_unit = shoelace.sl_unit
FROM shoelace_arrive shoelace_arrive, shoelace_ok shoelace_ok,
shoelace_ok *OLD*, shoelace_ok *NEW*,
shoelace shoelace, shoelace *OLD*,
shoelace *NEW*, shoelace_data shoelace_data
WHERE shoelace.sl_name = shoelace_arrive.arr_name
AND shoelace_data.sl_name = shoelace.sl_name;
이것은 다시 INSTEAD룰이므로, 이전의 쿼리 트리는 파기됩니다. 이 쿼리는 shoelace뷰를 계속해 사용하고 있는 것에 주의해 주세요. 그러나, 이 단계에서는 룰 시스템은 종료하고 있지 않기 때문에, 계속 _RETURN룰이 적용되어 아래와 같이 됩니다.
UPDATE shoelace_data
SET sl_name = s.sl_name,
sl_avail = s.sl_avail + shoelace_arrive.arr_quant,
sl_color = s.sl_color,
sl_len = s.sl_len,
sl_unit = s.sl_unit
FROM shoelace_arrive shoelace_arrive, shoelace_ok shoelace_ok,
shoelace_ok *OLD*, shoelace_ok *NEW*,
shoelace shoelace, shoelace *OLD*,
shoelace *NEW*, shoelace_data shoelace_data,
shoelace *OLD*, shoelace *NEW*,
shoelace_data s, unit u
WHERE s.sl_name = shoelace_arrive.arr_name
AND shoelace_data.sl_name = s.sl_name;
마지막으로, log_shoelace룰이 적용되어 이하와 같이 특별한 쿼리 트리가 생성됩니다.
INSERT INTO shoelace_log
SELECT s.sl_name,
s.sl_avail + shoelace_arrive.arr_quant,
current_user,
current_timestamp
FROM shoelace_arrive shoelace_arrive, shoelace_ok shoelace_ok,
shoelace_ok *OLD*, shoelace_ok *NEW*,
shoelace shoelace, shoelace *OLD*,
shoelace *NEW*, shoelace_data shoelace_data,
shoelace *OLD*, shoelace *NEW*,
shoelace_data s, unit u,
shoelace_data *OLD*, shoelace_data *NEW*
shoelace_log shoelace_log
WHERE s.sl_name = shoelace_arrive.arr_name
AND shoelace_data.sl_name = s.sl_name
AND (s.sl_avail + shoelace_arrive.arr_quant) <> s.sl_avail;
이 후, 룰 시스템은 룰을 다 사용해, 생성된 쿼리 트리를 돌려줍니다.
그리고, 이하의 SQL문과 등가가 되는 2개의 최종 쿼리 트리로 종결합니다.
INSERT INTO shoelace_log
SELECT s.sl_name,
s.sl_avail + shoelace_arrive.arr_quant,
current_user,
current_timestamp
FROM shoelace_arrive shoelace_arrive, shoelace_data shoelace_data,
shoelace_data s
WHERE s.sl_name = shoelace_arrive.arr_name
AND shoelace_data.sl_name = s.sl_name
AND s.sl_avail + shoelace_arrive.arr_quant <> s.sl_avail;
UPDATE shoelace_data
SET sl_avail = shoelace_data.sl_avail + shoelace_arrive.arr_quant
FROM shoelace_arrive shoelace_arrive,
shoelace_data shoelace_data,
shoelace_data s
WHERE s.sl_name = shoelace_arrive.sl_name
AND shoelace_data.sl_name = s.sl_name;
결과는, 1개의 릴레이션으로부터 온 데이터가 다른 릴레이션에 삽입되어 3번째의 릴레이션의 갱신으로 변경되고, 4번째의 갱신과 5번째에의 최종 갱신의 로그 기록으로 변경되어 최종적으로 2개의 쿼리에 축소됩니다.
조금 보기 좋지 않은 세부 사항이 있습니다. 완성된 2개의 쿼리를 보면, 1개로 축소되었음이 분명한 shoelace_data릴레이션이 범위 테이블에 두 번 나옵니다. 플래너는 처리를 하지 않기 때문에, INSERT의 룰 시스템의 출력에 대한 실행 계획은 다음과 같이 됩니다.
포개진 루프
-> 병합 결합
-> 시퀀셜 검색
-> 정렬
-> s에 대한 순서 검색
-> 시퀀셜 검색
-> 정렬
-> shoelace_arrive에 대한 시퀀셜 검색
-> shoelace_data에 대한 시퀀셜 검색
한편, 불필요한 범위 테이블 항목을 생략하는 것으로, 이하와 같이 로그 테이블에 완전히 같은 항목이 만들어집니다.
병합 결합
-> 시퀀셜 검색
-> 정렬
-> s에 대한 시퀀셜 검색
-> 시퀀셜 검색
-> 정렬
-> shoelace_arrive에 대한 시퀀셜 검색
그러니까, 룰 시스템은, 전혀 필요가 없는 shoelace_data릴레이션에 대한 불필요한 검색을 한 번 실시하게 됩니다. 그리고 UPDATE에서도 동일한 불필요한 검색이 재차 실행됩니다. 그렇지만, 이것들을 모두 가능하게 하는 것은 어려운 일입니다.
마지막에 PostgreSQL의 룰 시스템과 그 효과를 나타냅시다. 예를 들면, 전혀 팔릴 것 같지 않은 신발끈을 데이터베이스에 추가해 보겠습니다.
INSERT INTO shoelace VALUES ('sl9', 0, 'pink', 35.0, 'inch', 0.0);
INSERT INTO shoelace VALUES ('sl10', 1000, 'magenta', 40.0, 'inch', 0.0);
모든 구두에 맞지 않는 색이 shoelace항목에 있을지 없을지를 검사하는 뷰를 작성하고 싶다고 합니다. 뷰는 이하와 같이 됩니다.
CREATE VIEW shoelace_mismatch AS
SELECT * FROM shoelace WHERE NOT EXISTS
(SELECT shoename FROM shoe WHERE slcolor = sl_color);
이 출력은 이하와 같이 됩니다.
SELECT * FROM shoelace_mismatch; sl_name | sl_avail | sl_color | sl_len | sl_unit | sl_len_cm ---------+----------+----------+--------+---------+----------- sl9 | 0 | pink | 35 | inch | 88.9 sl10 | 1000 | magenta | 40 | inch | 101.6
여기서, 맞는 구두가 없는 신발끈 가운데, 재고가 없는 것을 데이터베이스로부터 삭제하도록 설정해 보겠습니다. 이것은 PostgreSQL에서는 곤란한 작업이므로, 직접 삭제하지 않습니다. 대신에, 이하와 같이 1개 뷰를 작성합니다.
CREATE VIEW shoelace_can_delete AS
SELECT * FROM shoelace_mismatch WHERE sl_avail = 0;
그리고, 이하를 실시합니다.
DELETE FROM shoelace WHERE EXISTS
(SELECT * FROM shoelace_can_delete
WHERE sl_name = shoelace.sl_name);
자 할 수 있었습니다.
SELECT * FROM shoelace; sl_name | sl_avail | sl_color | sl_len | sl_unit | sl_len_cm ---------+----------+----------+--------+---------+----------- sl1 | 5 | black | 80 | cm | 80 sl2 | 6 | black | 100 | cm | 100 sl7 | 6 | brown | 60 | cm | 60 sl4 | 8 | black | 40 | inch | 101.6 sl3 | 10 | black | 35 | inch | 88.9 sl8 | 21 | brown | 40 | inch | 101.6 sl10 | 1000 | magenta | 40 | inch | 101.6 sl5 | 4 | brown | 1 | m | 100 sl6 | 20 | brown | 0.9 | m | 90 (9 rows)
합계 4개의 포개진/결합된 뷰를 서브쿼리의 조건으로서 가져, 그 중의 하나는 뷰를 포함한 서브쿼리 조건을 가져, 한편 연산된 뷰의 열이 사용되는 경우의, 뷰에 대한 DELETE가, 실제 테이블에서 요구된 데이터를 삭제하는, 단일의 쿼리 트리에 고쳐 쓸 수 있습니다.
이러한 구조가 필요한 상황은 실제 상황에서는 거의 없다고 생각됩니다. 그러나, 실제로 작동하는 것을 확인할 수 있으면 안심할 수 있습니다.