SQL.18 外鍵與參照完整性：宣告、生效與查詢得到的保證

Wed, 02 Sep 2026 00:00:00 +0800

外鍵是一條寫在表結構上的宣告：這一欄的值，在另一張表裡找得到對應的那一列。資料庫在每一次寫入時檢查它，所以它涵蓋的是整張表，以及往後的每一筆資料。外鍵這條保證有一個名字叫參照完整性——「參照」指一欄指向另一張表的某一列，「完整」指那個指向落得到實處。

查詢的文字之外還有幾樣東西在決定結果——名字實際指向誰、送出的人被允許做什麼、引擎打算花多久。約束介入得比那幾樣都早：它決定資料能長成什麼樣，於是決定一段查詢會遇到哪幾種列。

本篇走完這條保證的全貌：它擋下哪些寫入、什麼時候才算生效、生效之後查詢省掉哪一步、父列消失時它怎麼維持，以及它涵蓋不到的地方。這條約束該不該加是資料表設計的取捨，本篇只處理加了之後寫入與查詢的行為有什麼改變。

本篇的表在共用資料庫上重建，差別是這一次把約束寫進結構裡；顧客表的三個人是佳穎、宗翰、雅文，而只有佳穎下過單。後面談替既有的表補約束時，另外用到一張出貨表。指不到父列的那一列，下文叫孤兒列。

外鍵擋下的寫入與 NULL 的放行

外鍵管的是兩張表之間的一個指向，而破壞這個指向的寫入來自兩邊。子表這一側是填進一個指不到的值，父表那一側是把還被指著的那一列刪掉。

1CREATE TABLE 訂單 (訂單編號 INT PRIMARY KEY,
2                   顧客編號 INT REFERENCES 顧客(顧客編號), 下單日 TEXT, 金額 INT);
3CREATE TABLE 評價 (評價編號 INT PRIMARY KEY,
4                   訂單編號 INT REFERENCES 訂單(訂單編號), 星等 INT);

1-- PostgreSQL 18
2INSERT INTO 評價 VALUES (9003, 999, 4);
3ERROR:  insert or update on table "評價" violates foreign key constraint "評價_訂單編號_fkey"
4DETAIL:  Key (訂單編號)=(999) is not present in table "訂單".
5
6DELETE FROM 顧客 WHERE 顧客編號 = 1;
7ERROR:  update or delete on table "顧客" violates foreign key constraint "訂單_顧客編號_fkey" on table "訂單"
8DETAIL:  Key (顧客編號)=(1) is still referenced from table "訂單".

上面兩則錯誤訊息裡的約束名不同。第一則是評價表自己那條，第二則是訂單表那條——刪顧客這個動作在訂單表上觸發檢查，所以擋下它的約束掛在訂單表上。外鍵的錯誤訊息因此要分兩層讀：訊息指名的表，未必是剛才那句 SQL 寫到的表。

有一個值在子表與父表兩邊都放行：NULL。單欄的外鍵讀作「這一欄有值的時候，那個值找得到對應」，所以空著的那一欄不參與檢查。跨多欄的外鍵預設另有一種讀法——標準的預設 MATCH SIMPLE 只要其中一欄是 NULL 就整條放行，另外幾欄有值也不查。要它回到逐欄都算的讀法得寫 MATCH FULL，而這個寫法只在 PostgreSQL 上生效。同一列 (999, NULL) 寫進兩欄外鍵、而 999 在父表裡不存在時，各引擎的結果是：

 1-- 父表以 (a, b) 兩欄為主鍵，999 在父表裡不存在
 2CREATE TABLE 父 (a INT, b INT, PRIMARY KEY (a, b));
 3CREATE TABLE 子_預設 (a INT, b INT, FOREIGN KEY (a, b) REFERENCES 父 (a, b));
 4CREATE TABLE 子_完整 (a INT, b INT, FOREIGN KEY (a, b) REFERENCES 父 (a, b) MATCH FULL);
 5
 6-- 預設 MATCH SIMPLE：有一欄是 NULL，整條放行，另一欄不查
 7INSERT INTO 子_預設 VALUES (999, NULL);
 8-- PostgreSQL 18：收下
 9
10-- 宣告成 MATCH FULL：逐欄都算
11INSERT INTO 子_完整 VALUES (999, NULL);
12-- PostgreSQL 18：拒絕，MATCH FULL does not allow mixing of null and nonnull key values
13-- SQLite 3.51（已開 PRAGMA foreign_keys）、MySQL 8.4：收下 MATCH FULL 這個語法，照樣放行同一列

在 SQLite 與 MySQL 上要擋下混著空與非空的組合，得在每一欄各自加 NOT NULL。訂單編號留空的評價插得進去，而它是一則指不到任何訂單的評價——SQL.13 查詢的合法性與答案的正確性：引擎檢查的範圍、答案錯掉的成因與查證方法裡「NOT IN」的錯法要回零列，要的正是這樣一列。要連訂單編號留空的評價也擋掉，評價表的訂單編號另外要有 NOT NULL。

NULL 放行這件事在一種結構裡是必要的：外鍵指回自己所在的那張表。員工表的主管欄指向同一張表的另一列時，一列的上層是同一張表的另一列，而最頂層那一列的主管欄只能留空。這個結構的查詢要把同一張表擺兩次，兩次出現需要各自的名字，SQL.7 表的出現與別名：表名的指稱、別名的作用範圍與自連接寫自連接為什麼非取名不可，並把它處理的關係分成前後配對、同組比較與層級關係三種形態——員工與主管屬於層級關係。

宣告與生效分開的位置：連線設定、約束狀態、語法形態與儲存引擎

同一段 REFERENCES 送進不同的引擎，會落在不同的狀態。宣告與生效在連線的設定、約束自己的狀態、語法的形態、表的儲存引擎這幾個位置各自分開過一次，而它們讓人察覺宣告與生效已經分岔的難易程度差很多。

連線的設定。SQLite 認得 REFERENCES 這段語法、也把約束記進結構裡，而檢查預設關閉，開關掛在每一條連線上：

1-- SQLite 3.51，未開 PRAGMA
2INSERT INTO 評價 VALUES (9003, 999, 4);   -- 成功，孤兒列進來了
3
4-- 同一個檔案，開了之後
5PRAGMA foreign_keys = ON;
6INSERT INTO 評價 VALUES (9004, 888, 4);
7Error: stepping, FOREIGN KEY constraint failed (19)

開關打開之後，開關關著時插進去的那筆孤兒列（9003）仍然在表裡——檢查發生在寫入的當下，對已經在裡面的資料沒有追溯力。把孤兒列找出來的指令是 PRAGMA foreign_key_check：

1PRAGMA foreign_key_check;
2-- table | rowid | parent | fkid
3-- 評價  | 2     | 訂單   | 0
4--   違反者所在的表、那一列的 rowid、被指向的表，以及那是這張表上的第幾條外鍵（從 0 起算）
5--   評價編號宣告成 INT PRIMARY KEY 而不是 INTEGER PRIMARY KEY，所以 rowid 是另一個隱藏欄位，不等於評價編號

約束自己的狀態。PostgreSQL 的 NOT VALID 讓一條外鍵掛上去而略過既有的列，往後的寫入照常檢查。這個狀態是給大表補約束用的（既有列的檢查另用 VALIDATE CONSTRAINT 分開跑，避免長時間鎖表），而它留下的中間態是：表上有這條約束，表裡有孤兒列。

 1-- PostgreSQL 18，出貨表裡已經有一列指向不存在的訂單 777
 2CREATE TABLE 出貨 (出貨編號 INT PRIMARY KEY, 訂單編號 INT);
 3INSERT INTO 出貨 VALUES (1, 102), (2, 777);
 4
 5ALTER TABLE 出貨 ADD CONSTRAINT 出貨_訂單編號_fkey
 6  FOREIGN KEY (訂單編號) REFERENCES 訂單(訂單編號) NOT VALID;
 7-- 成功，777 那一列沒有被檢查
 8
 9INSERT INTO 出貨 VALUES (3, 888);
10-- ERROR:  insert or update on table "出貨" violates foreign key constraint "出貨_訂單編號_fkey"
11
12ALTER TABLE 出貨 VALIDATE CONSTRAINT 出貨_訂單編號_fkey;
13-- ERROR:  insert or update on table "出貨" violates foreign key constraint "出貨_訂單編號_fkey"
14-- DETAIL:  Key (訂單編號)=(777) is not present in table "訂單".

語法的形態。MySQL 認得欄位層的 REFERENCES，解析完把它丟掉，不留下任何約束，SHOW WARNINGS 也是空的。同一段文字在 PostgreSQL 與 SQLite 底下建得出約束，在 MySQL 底下建不出來，而 MySQL 在建表時沒有給任何警告。

表的儲存引擎。同一家 MySQL 裡還有一條讓宣告消失的路，而它多半不是有人刻意選的——舊系統的建表模板、從舊備份還原回來的表、或複製過來的一段舊 DDL，都會把儲存引擎一起帶進來。表層的 FOREIGN KEY 寫法建在 MyISAM 上，語法照收、警告照樣是空的，約束同樣沒有留下。兩條路要改的地方不同：欄位層的寫法要改寫成表層的 FOREIGN KEY，MyISAM 要換成 InnoDB。

 1-- MySQL 8.4，資料庫名 t；顧客表同共用資料，並以顧客編號為主鍵
 2-- 欄位層的 REFERENCES：建表成功，SHOW WARNINGS 是空的
 3CREATE TABLE 訂單 (訂單編號 INT PRIMARY KEY,
 4                   顧客編號 INT REFERENCES 顧客(顧客編號), 下單日 TEXT, 金額 INT);
 5INSERT INTO 訂單 VALUES (103, 999, '2026-03-10', 200);
 6-- 成功，孤兒列進來了
 7
 8-- 表層的 FOREIGN KEY，建在預設的 InnoDB 上
 9CREATE TABLE 訂單_表層 (訂單編號 INT PRIMARY KEY, 顧客編號 INT, 下單日 TEXT, 金額 INT,
10                        FOREIGN KEY (顧客編號) REFERENCES 顧客(顧客編號));
11INSERT INTO 訂單_表層 VALUES (103, 999, '2026-03-10', 200);
12-- ERROR 1452 (23000): Cannot add or update a child row: a foreign key constraint fails
13
14-- 同樣的表層寫法建在 MyISAM 上：建表成功，SHOW WARNINGS 是空的
15CREATE TABLE 訂單_MyISAM (訂單編號 INT PRIMARY KEY, 顧客編號 INT, 下單日 TEXT, 金額 INT,
16                          FOREIGN KEY (顧客編號) REFERENCES 顧客(顧客編號)) ENGINE=MyISAM;
17INSERT INTO 訂單_MyISAM VALUES (103, 999, '2026-03-10', 200);
18-- 成功，孤兒列進來了
19
20SELECT TABLE_NAME FROM information_schema.REFERENTIAL_CONSTRAINTS
21 WHERE CONSTRAINT_SCHEMA = 't';
22-- 訂單_表層    三張表裡只有這一張留下了約束

這幾個位置的共同點是外鍵只在寫入的那一刻現身：查詢的文字裡沒有一個字提到約束，讀的時候也沒有差別。所以「這條保證在不在」要另外查，查的地方是系統目錄。系統目錄記的是宣告存不存在，生不生效要另外查：SQLite 在 PRAGMA foreign_keys 關著的時候照樣列出那條外鍵，而孤兒列插得進去；PostgreSQL 的 NOT VALID 外鍵同樣列在 information_schema.table_constraints 裡。

 1-- 宣告存不存在
 2-- PostgreSQL
 3SELECT table_name, constraint_name FROM information_schema.table_constraints
 4 WHERE constraint_type = 'FOREIGN KEY';
 5-- MySQL
 6SELECT TABLE_NAME, CONSTRAINT_NAME FROM information_schema.REFERENTIAL_CONSTRAINTS
 7 WHERE CONSTRAINT_SCHEMA = 't';
 8-- SQLite：每張表各查一次
 9PRAGMA foreign_key_list(評價);
10-- 0|0|訂單|訂單編號|訂單編號|NO ACTION|NO ACTION|NONE    開關關著的時候也列得出來
11
12-- 生不生效
13-- SQLite：這條連線的開關
14PRAGMA foreign_keys;
15-- 0 是關、1 是開
16-- PostgreSQL：convalidated 是 f 的外鍵是 NOT VALID，既有的列沒有檢查過
17SELECT conname, convalidated FROM pg_constraint WHERE contype = 'f';
18-- 出貨_訂單編號_fkey | f
19-- 訂單_顧客編號_fkey | t
20-- 評價_訂單編號_fkey | t

生效之後還有一個「什麼時候檢查」的維度。預設是每一句寫入當場檢查，而 PostgreSQL 的 DEFERRABLE INITIALLY DEFERRED 把檢查推到交易提交的那一刻——中間的每一句都通過，COMMIT 才回 violates foreign key constraint。互相指向的兩張表要一起寫入時需要這個推遲——部門有一欄指向它的主管、員工有一欄指向所屬部門，兩欄都不能是空的時候，兩張表都得先有對方的一列才寫得進去。這種形態下沒有推遲就沒有第一筆資料。代價是錯誤浮現的位置離寫錯的那一句遠了一整個交易。

 1-- PostgreSQL 18，兩條外鍵都宣告成 DEFERRABLE INITIALLY DEFERRED
 2CREATE TABLE 部門 (部門編號 INT PRIMARY KEY, 主管 INT NOT NULL);
 3CREATE TABLE 員工 (員工編號 INT PRIMARY KEY,
 4                   部門編號 INT NOT NULL REFERENCES 部門 DEFERRABLE INITIALLY DEFERRED);
 5ALTER TABLE 部門 ADD FOREIGN KEY (主管) REFERENCES 員工 DEFERRABLE INITIALLY DEFERRED;
 6
 7BEGIN;
 8INSERT INTO 部門 VALUES (1, 10);   -- 員工 10 還不存在，這一句照樣通過
 9INSERT INTO 員工 VALUES (10, 1);
10COMMIT;                            -- 提交時兩條外鍵都滿足
11
12BEGIN;
13INSERT INTO 部門 VALUES (2, 20);   -- 通過
14COMMIT;
15-- ERROR:  insert or update on table "部門" violates foreign key constraint "部門_主管_fkey"
16-- DETAIL:  Key (主管)=(20) is not present in table "員工".
17--   同樣兩張表不宣告 DEFERRABLE 的話，兩句 INSERT 無論哪一句先寫都當場被擋下

約束生效之後查詢可以省掉的判斷：NOT NULL 與外鍵各自的保證

一條保證的價值落在它讓哪些判斷不必再做。同一組表的兩個版本擺在一起看得清楚：一邊的 訂單.顧客編號 帶著 NOT NULL REFERENCES 顧客(顧客編號)，另一邊什麼都沒有，而沒有約束的那一版收了一張顧客編號留空的訂單。

 1-- SQLite 3.51，已開 PRAGMA foreign_keys
 2-- 有約束的版本
 3CREATE TABLE 訂單 (訂單編號 INT PRIMARY KEY,
 4                   顧客編號 INT NOT NULL REFERENCES 顧客(顧客編號), 下單日 TEXT, 金額 INT);
 5INSERT INTO 訂單 VALUES (101,1,'2026-03-02',300), (102,1,'2026-03-09',500);
 6INSERT INTO 訂單 VALUES (103, NULL, '2026-03-10', 200);
 7-- NOT NULL constraint failed: 訂單.顧客編號
 8-- 沒有約束的版本（共用資料的建表語句）收下同一列
 9
10-- 兩個版本各跑一次
11SELECT count(*) FROM 訂單 JOIN 顧客 ON 顧客.顧客編號 = 訂單.顧客編號;
12-- 有約束：2，訂單表 2 列
13-- 沒有約束：2，訂單表 3 列；103 配不到任何顧客，從結果裡消失
14
15SELECT 姓名 FROM 顧客 WHERE 顧客編號 NOT IN (SELECT 顧客編號 FROM 訂單);
16-- 有約束：宗翰、雅文
17-- 沒有約束：0 列；子查詢交出 1、1、NULL，與 NULL 比較的那一項是未知

沒有約束的那一版，內連接與 NOT IN 這兩段查詢各自出了一種錯，而兩種都不報錯。內連接掉了一列，而總數看起來仍然像一份完整的訂單清單；NOT IN 整段回空集合，因為子查詢交出的那一欄含一個 NULL。內連接為什麼丟掉配不到對象的列，在 Outer Join（外連接）；NOT IN 的完整推導在 SQL.6 連接之後的列數與空缺：列數膨脹、外連接補的 NULL 與三值邏輯的「子查詢含 NULL 時的 NOT IN 與 NOT EXISTS」一節。

有約束的那一邊，兩段查詢都對，而它們的寫法一個字都沒改。改變的是那兩個判斷的前提從觀察變成了保證：翻遍現在的訂單表沒有一筆顧客編號是空的，只證明此刻如此；NOT NULL 證明的是往後也不會有，而查詢要活得比這一批資料久（Constraint）。

這裡有兩條約束在做不同的事，分開記各自買到什麼。NOT NULL 買的是「這一欄有值」，它管掉上面兩種錯——沒有空缺，內連接就掉不了列，NOT IN 也碰不到那個 NULL。外鍵買的是「這個值指得到人」，它管的是另一批推論：這一欄有值的列，連過去必定配得到一列。子表的每一列都歸屬到某個父列、JOIN 與 LEFT JOIN 在這個方向上回同一批列，這兩項要兩條約束都在才成立——只有外鍵的時候，顧客編號留空的訂單照樣寫得進去，LEFT JOIN 留下它而 JOIN 丟掉它。兩條都在的時候，「這個連接會掉列嗎」這個問題不必查資料就答得出來。UNIQUE 保證值不重複、CHECK 保證值滿足一個自己寫的條件、PRIMARY KEY 是 NOT NULL 加 UNIQUE 再加上「這是辨識一列的依據」，而這幾種約束共用同一條性質——豁免一個判斷的條件必須是一條約束，不能是一次觀察；各自買到什麼、以及它們為什麼住在 DDL 那一側，在 Constraint（約束）。

這些推論的代價落在寫入那一側：每插進一列，資料庫要去父表確認那個值在不在，所以外鍵是拿寫入的工作換讀取的保證。這筆交換要用量測來判，而讀代價的工具在 SQL.17 查詢的代價。要不要加這條外鍵約束，則是設計的決定：它在強制完整性與演進自由度之間取捨：正式的核心資料通常由資料庫強制，換取每一次讀取都能信任的推論；跨系統整合的資料常改由應用層保護，因為上游的結構可能先變，外鍵會讓那一次變動變成寫入失敗——Schema Design 的「Table 與 Relation」一節寫這個取捨，並提醒宣告與執法要分開看。

父列被刪除時子列的去向：ON DELETE 的選項

擋下刪除是預設，而它把問題丟回給寫入的那一方：顧客要停用了，他的訂單怎麼辦。這個決定寫在外鍵的宣告裡，跟著約束走而不是跟著每次刪除走。

1訂單編號 INT REFERENCES 訂單(訂單編號) ON DELETE CASCADE      -- 子列一起刪掉
2訂單編號 INT REFERENCES 訂單(訂單編號) ON DELETE SET NULL     -- 子列留著，這一欄清空
3訂單編號 INT NOT NULL DEFAULT 0
4            REFERENCES 訂單(訂單編號) ON DELETE SET DEFAULT  -- 子列留著，改指一個哨兵列

在 PostgreSQL 18 上刪掉訂單 102，三種寫法的子列各自落到宣告寫的去向：

1-- 三張評價表照上面三行宣告，各有一列 (9001, 102, 4)；訂單 0 是事先備好的哨兵列
2DELETE FROM 訂單 WHERE 訂單編號 = 102;
3
4SELECT * FROM 評價_連帶刪除;   -- ON DELETE CASCADE：0 列
5SELECT * FROM 評價_清空;       -- ON DELETE SET NULL：9001 |   | 4，訂單編號變成空的
6SELECT * FROM 評價_改指哨兵;   -- ON DELETE SET DEFAULT：9001 | 0 | 4，改指哨兵列

擋下刪除的則有兩種寫法而它們不一樣：RESTRICT 在那一句 DELETE 當場擋下，而且不能推遲；NO ACTION（沒寫 ON DELETE 時的預設）在每一句結束時檢查，約束宣告成 DEFERRABLE 之後才能推到交易提交。同一個交易裡先刪父列、再刪子列，只有宣告成 DEFERRABLE 的 NO ACTION 過得去。

子列離開父列之後還有沒有意義，決定它跟著刪掉還是留下。 一則評價離開它評的那張訂單之後說不出在評什麼，所以它適合跟著走；一筆出貨紀錄即使訂單被撤銷仍然是發生過的事實，清空指向比刪掉它更貼近實情。

這一列有沒有自己的保留義務，是獨立的另一個問句，而它成立的時候蓋過「還有沒有意義」的答案。 一筆交易紀錄離開它的帳戶之後同樣說不出在記什麼，只問還有沒有意義會走到 CASCADE——而受稽核或法規保留的紀錄不能被任何一次刪除帶走。保留義務成立的時候，答案落在 RESTRICT 或 SET DEFAULT 上（RESTRICT 不准刪父列，SET DEFAULT 讓子列改指一個「已刪除」的哨兵列，紀錄留著而那一欄不為空），而只問還有沒有意義的時候，這兩個選項不會被想到。保留義務要優先的理由是 CASCADE 的一個性質：一次刪除實際刪掉多少，由表之間的結構決定，不由那句 DELETE 決定。它沿著外鍵一路傳下去，刪一個顧客連帶刪掉他的訂單、那些訂單的評價，以及再往下的每一層，而那句 SQL 的文字裡只提到顧客。

SET NULL 與同一欄上的 NOT NULL 要求的條件互相排斥，而建表的時候兩者並存不會被擋下。PostgreSQL 18 收下這張表，衝突到刪除父列的那一刻才浮現，訊息指的是那個清空的動作違反了 NOT NULL：

1-- PostgreSQL 18
2CREATE TABLE 評價 (評價編號 INT PRIMARY KEY,
3                   訂單編號 INT NOT NULL REFERENCES 訂單(訂單編號) ON DELETE SET NULL, 星等 INT);
4-- 建表成功
5INSERT INTO 評價 VALUES (9001, 101, 5);
6DELETE FROM 訂單 WHERE 訂單編號 = 101;
7-- ERROR:  null value in column "訂單編號" of relation "評價" violates not-null constraint
8-- DETAIL:  Failing row contains (9001, null, 5).
9-- CONTEXT:  SQL statement "UPDATE ONLY "public"."評價" SET "訂單編號" = NULL WHERE ..."

宣告與生效那條分界在這裡又出現一次：宣告收下了，做得到做不到要等到執行的那一刻。 而 NOT NULL 買掉的正是掉列與 NOT IN 那兩類錯誤，所以這裡要選一邊——留下子列的代價是那一欄重新可能為空，關於它的推論回到觀察那一級。

外鍵涵蓋不到的寫入與規則

外鍵的檢查發生在寫入的那一刻，所以它的射程由「哪些寫入經過它」決定。

既有的資料不在射程裡。 補一條外鍵到已經有孤兒列的表上，這個動作本身會失敗：

1-- PostgreSQL 18，出貨表裡有一列的訂單編號是 777
2ALTER TABLE 出貨 ADD FOREIGN KEY (訂單編號) REFERENCES 訂單(訂單編號);
3ERROR:  insert or update on table "出貨" violates foreign key constraint "出貨_訂單編號_fkey"
4DETAIL:  Key (訂單編號)=(777) is not present in table "訂單".

這則錯誤說的是資料裡已經有孤兒列，而約束加得上去的條件，是既有的每一列都已經滿足它。給有流量的大表補約束的完整順序在資料庫轉換實作的「Type I：加約束（CHECK / FK / NOT NULL 收緊）」一節。

同一個資料庫之外的指向不在射程裡。 外鍵認的是另一張表，所以一個指向別的服務的識別碼、或指向物件儲存的一個鍵，資料庫無從檢查。這一類的完整性要在資料庫以外的層落地。應用程式碼內部的落點分幾層、各層違反規則時發生什麼，在不變式的強制層次——那一篇的作用域是單一物件的規則。跨服務的一致性靠什麼維持（Saga、outbox 這一類），在 Transaction 與一致性邊界，那一篇談的是一致性，參照完整性要落在哪一層它沒有單獨處理。

不經過這條連線的寫入不在射程裡。 這一點是 SQLite 把 PRAGMA foreign_keys 開關掛在每一條連線上的直接後果——約束的檢查掛在連線上的時候，遷移工具、測試框架與別人的第三方程式各自開自己的連線，而它們未必開了那個開關。射程因此不是「這個資料庫」，是「經過設定正確的連線的那些寫入」。

業務規則不在射程裡。 外鍵回答的問題只有一個：這個值在那張表裡找不找得到。「評價要在出貨之後」「同一張訂單只能退款一次」沒有這個形狀，而兩條規則各自落在不同的機制上：「同一張訂單只能退款一次」要比對退款表裡同一張訂單的其他列，寫成退款表訂單編號上的 UNIQUE；「評價要在出貨之後」要讀出貨表裡那張訂單的出貨時間，而 CHECK 只讀正要寫入的那一列、不接受子查詢，所以它落在觸發器或應用層。

業務規則那一項接上 SQL.13 查詢的合法性與答案的正確性：引擎檢查的範圍、答案錯掉的成因與查證方法的一個結論：「答案對不對」整條交不出去，而它底下的判斷能不能交給機器，看判斷時要讀什麼——在寫入那一刻就判得完、而且讀的範圍對得上某一種約束的，寫得成約束：CHECK 只讀正要寫入的那一筆，UNIQUE 讀同一欄已有的值，外鍵讀另一張表裡被指向的那一列。外鍵是約束裡讀得最遠的一種，而讀的範圍到被指向的那一列為止；「評價要在出貨之後」要讀另一張表的出貨日，同樣在寫入那一刻判得完，卻超出了每一種約束的範圍。

文字的宣告被執行的程度：外鍵、引擎補上的決定與 LEFT JOIN

一段文字說的話什麼時候會被執行，外鍵是答案最明確的那一端：它有生效的狀態可查，查得到之後保證就在。LEFT JOIN 的 LEFT 也宣告了一件事——預期有配不到的列——而引擎從不查證它，照著算完就結束，宣告落空時查詢照樣回正確答案；那一端在 SQL.20 關鍵字的宣告與引擎的行為：宣告落空的形態與查證。夾在中間的是引擎替文字補上的決定：外鍵在某一家被靜默丟掉就是其中一例，這一類差異按發聲的位置從當場報錯分到完全靜默、並依同一段 SQL 要跑在幾種引擎與設定的組合上，決定哪幾種要在寫的當下就處理掉，在 SQL.19 引擎寬鬆度與可攜性：各家對同一組寫法的差異、分級與處理時機。