本篇要用到這兩層的名字。合法指上一段那三項檢查都通過——判它不必讀任何一列資料，但要知道是哪一家引擎在判：各家收與不收的界線不同，標準禁止的寫法有的引擎照收，而那條界線劃在哪裡、各家怎麼劃，在 SQL.19 引擎寬鬆度與可攜性：各家對同一組寫法的差異、分級與處理時機；問對了指算出來的那份關係（欄位固定、由若干列構成的集合，查詢的結果就是一份關係）正好是那個問題的答案，這個詞是本篇為了指認「這批列是不是那個問題的答案」這一層而取的，SQL 的標準術語裡沒有它。

語意模型指這個語言規定的、由查詢的文字算出結果的那套規則，它的每一項規則都有一處與直覺相反（子句的先後、連接的左右、條件擺哪一邊、分組的鍵各是一例）。本篇處理直覺錯掉之後會發生什麼：引擎照樣算完、照樣回一批結果，而那批結果不帶任何出錯的訊號。

正解與錯的寫法：「不等於五」「漏掉星等」與「NOT IN」

書店要找出沒有五星評價的訂單。共用資料裡訂單 101 有一則五星、訂單 102 沒有評價，所以答案是 102。

正確的寫法把星等的條件放進 ON，再挑配不到的那些（SQL.5 ON 與 WHERE：連接條件與篩選條件各自的職責 的「找沒配到的那些列：IS NULL 條件的歸屬」一節）：

1SELECT 訂單.訂單編號 FROM 訂單
2LEFT JOIN 評價 ON 評價.訂單編號 = 訂單.訂單編號 AND 評價.星等 = 5
3WHERE 評價.評價編號 IS NULL;
4-- 102

「不等於五」的錯法把「沒有五星」寫成「星等不等於五」。 其餘不動，只把星等條件挪進 WHERE 並改成不等於：

1... LEFT JOIN 評價 ON 評價.訂單編號 = 訂單.訂單編號
2WHERE 評價.星等 <> 5;
3-- 共用資料：0 列
4--   101 唯一那則評價是五星，5 <> 5 判成假
5--   102 沒有評價，外連接替它補一列、星等是 NULL，NULL <> 5 的真值是未知，WHERE 只留判成真的列
6-- 訂單 101 多一則三星之後：101

這一段問的是「至少有一則非五星評價的訂單」，與「沒有五星評價的訂單」是兩個不同的問題。外連接替配不到評價的訂單補出來、評價欄位全是 NULL 的那一列，MySQL 手冊叫 NULL-complemented row，本篇寫成補出來的列；對補出來的列判不成真的篩選條件叫拒絕 NULL 的條件（null-rejected condition），評價.星等 <> 5 就是一例（NULL 參與比較時為什麼判成未知，在 SQL.6 連接之後的列數與空缺 的「NULL 的比較結果與 IS NULL」一節）。問錯了問題，加上拒絕 NULL 的條件把補出來的列全數濾掉，兩件疊在一起，所以這段查詢回哪些列由資料決定：訂單 101 多一則三星之後，正解仍然是 102，而它交出了恰好相反的那一列。

補一個 IS NULL 讓補出來的列留下也修不掉，它在兩批資料上一次對、一次錯：

1... LEFT JOIN 評價 ON 評價.訂單編號 = 訂單.訂單編號
2WHERE 評價.星等 <> 5 OR 評價.星等 IS NULL;
3-- 共用資料：102，看起來完全正確
4-- 訂單 101 多一則三星之後：101 與 102

補上的只是補出來的列，問題仍然是「至少有一則非五星評價」。

「漏掉星等」的錯法把星等條件整個漏掉，而它在現有資料上回了正確答案。 這一種的星等條件哪裡都沒出現：

1SELECT 訂單.訂單編號 FROM 訂單
2LEFT JOIN 評價 ON 評價.訂單編號 = 訂單.訂單編號
3WHERE 評價.評價編號 IS NULL;
4-- 共用資料：102
5-- 訂單 102 多一則三星評價之後：0 列（正解仍然是 102）

這一段問的是「沒有任何評價的訂單」。它與正解在共用資料上是同一批列，因為有評價的那張訂單剛好只有五星那一則；兩段查詢要到某張訂單的評價全部不是五星時才分開。

「NOT IN」的錯法用 NOT IN 表達否定的成員判斷。 星等條件回到子查詢裡，連接整個省掉：

 1SELECT 訂單編號 FROM 訂單
 2WHERE 訂單編號 NOT IN (SELECT 訂單編號 FROM 評價 WHERE 星等 = 5);
 3-- 共用資料：102
 4-- 評價表多一則訂單編號還沒填的五星評價之後：0 列
 5--   子查詢交出 101 與 NULL，NOT IN 對訂單 102 展開成 102 <> 101 AND 102 <> NULL
 6--   前一項為真、後一項的真值是未知，AND 的結果是未知，WHERE 不留
 7
 8-- 同一個問題寫成 NOT EXISTS，加了那則評價之後仍然回 102
 9SELECT 訂單編號 FROM 訂單
10WHERE NOT EXISTS (SELECT 1 FROM 評價
11                  WHERE 評價.訂單編號 = 訂單.訂單編號 AND 星等 = 5);

NOT IN 展開成一串「不等於」的 AND，子查詢只要交出一個 NULL，那一項對每一列都判成未知，整串因此不會是真（完整推導在 SQL.6 連接之後的列數與空缺：列數膨脹、外連接補的 NULL 與三值邏輯 的「子查詢含 NULL 時的 NOT IN 與 NOT EXISTS」一節）。NOT EXISTS 逐列問「有沒有一則配得上的五星評價」，訂單編號是 NULL 的那則評價配不上任何一張訂單，所以不影響結果。

答案錯掉的成因分類與引擎不報錯的原因

從要問的那一題到算出來的那批列，中間經過三個環節：提問的人把問題寫成查詢文字、語意模型規定這段文字算出什麼、引擎照它的實作去算。答案錯掉的成因按斷在哪一個環節分類：斷在問題寫成文字的，本篇叫問錯了問題；寫的人對某條規則的預期與語意模型的規定不同，叫誤解語意模型；引擎的行為偏離標準，叫引擎寬鬆；另有一類不斷在任何環節，而是要問的那一題本身還沒成形，叫問題還沒決定。

「不等於五」與「漏掉星等」問錯了問題。「不等於五」問的是「至少有一則非五星評價」，「漏掉星等」問的是「有沒有任何評價」——兩段查詢都精確地回答了它們自己問的那一題，而那一題不是要問的那一題。問錯了問題與模型的規則無關：換引擎、加約束都碰不到它，因為那段文字沒有任何一處是錯的；靜態分析判得出「不等於五」，憑的是它同時誤解了語意模型（見〈「問對了沒有」的判定：靜態分析、約束與反例資料〉）。問題與查詢文字之間還有反方向的落差，SQL.20 關鍵字的宣告與引擎的行為：宣告落空的形態與查證 叫它宣告落空：查詢的答案是對的，錯的是文字對下一個讀它的人說的話，例如 LEFT 宣告了一個從未發生的情況。問錯了問題的落差在問題與文字之間，宣告落空在文字與行為之間。

「NOT IN」的錯法誤解語意模型。NOT IN 的展開方式由模型定死，而寫的人預期它表現得像「不在這個集合裡」。誤解語意模型修得掉，改對之後永遠對。分頁是誤解語意模型的另一個實例：同分的列排在哪裡模型沒有規定，而逐頁取的人預期它固定，SQL.12 分頁的排序鍵與接續標記 寫它怎麼變成重複與遺漏。

「不等於五」的錯法同時屬於問錯了問題與誤解語意模型——它問的那個問題不是要問的，而它的星等條件又是拒絕 NULL 的條件、把補出來的列全數濾掉——所以它回的列隨資料變動，這是它比「漏掉星等」與「NOT IN」難診斷的原因。

引擎寬鬆的實例不在這三種錯法裡。引擎接受了標準禁止的寫法並自己補一個值：分組之後把非分組欄放進 SELECT，實例住在 SQL.2 子句的求值順序 與 SQL.9 分組鍵的選擇：鍵與一組所代表的對象，換一家引擎就浮現。SQL.2 除了求值順序，也寫了哪些違反求值順序的寫法會被引擎當場報錯、哪些會被照收——同一個放錯邊的條件在一家報錯、在另一家回一份錯的清單。問題還沒決定的實例是「所有訂單都被評價過的顧客」：它在一張訂單都沒下過的人身上為真（邏輯裡叫空真，vacuous truth），而提問的人多半還沒想過那算不算。問題還沒決定連換誰來寫都不會浮現，因為要問的那一題還沒成形。

這些成因有一個共通的地方：引擎回給寫查詢的人的只有兩樣，錯誤訊息與算出來的那批列，而這些錯誤在兩樣裡都不現形。引擎保證的是兩件事：這段文字合法，而算出來的關係符合語意模型。文字合法與關係符合語意模型這兩項都不決定答案對不對，而答案對不對也不影響這兩項，所以錯誤沒有任何一條經由引擎回報的管道。 三段查詢一則錯誤訊息都沒有，沒有型別衝突，沒有一列長得奇怪。

回來的那批列本身也看不出答案錯了，而看不出來的情形不只一種。「漏掉星等」的錯法在原本那批資料上回了正確答案，看不出問題；「不等於五」與「NOT IN」兩種回零列，而零列既可能是「確實沒有」也可能是條件整段失效——分不出這兩者，正是 SQL.8 IN、EXISTS 與 JOIN 把否定式一律交給 NOT EXISTS 的理由。結果的形狀正確也不構成保證。把訂單接上評價再加總金額：

1SELECT SUM(訂單.金額) FROM 訂單
2LEFT JOIN 評價 ON 評價.訂單編號 = 訂單.訂單編號;
3-- 共用資料：800（101 是 300、102 是 500）
4-- 替 101 再加一則評價之後：1100
5--   101 配到兩則評價，連接後那張訂單變成兩列，300 算了兩次

兩次回來的都是一列一欄的一個數字，形狀與正確答案沒有任何不同（連接為什麼會複製列，在 SQL.6 連接之後的列數與空缺：列數膨脹、外連接補的 NULL 與三值邏輯）。

「漏掉星等」的錯法另有一個性質：它在寫下的當時通得過任何檢驗。拿現有資料驗它，答案是對的；逐句讀它，每一個子句都符合語法與模型。

「問對了沒有」的判定：靜態分析、約束與反例資料

「問對了沒有」需要一個答案來比對，而那個答案不在查詢裡，也不在資料裡——它在提問的人手上。所以這一層交不出一條可以機械執行的判定——任何規則都得先知道要問的是什麼，才說得出這批列對不對。

「問對了沒有」這整條判定交不出去，而它底下有幾項較小的判斷交得出去。 一項判斷能不能交給機器，看判斷時要讀的資訊，機器在做這項判斷的那一刻讀不讀得到：引擎收到查詢的時候讀得到查詢的文字與表的結構，資料庫寫入一筆資料的時候讀得到那一筆資料與資料庫當下已有的列，而「要問的是什麼」只有提問的人知道。這些判斷因此按它們要讀什麼分開：只讀查詢文字與表結構的是靜態分析，只讀寫入那一刻資料庫裡的資料的寫成約束，要讀「要問的是什麼」的，機器能接手的只有比對——提問的人先造一筆反例資料、給出它對應的正確答案，機器負責比對查詢回的答案與它是否相同。

靜態分析只讀查詢的文字與表的結構，判斷時不需要任何一列資料，也不需要提問的人。 「不等於五」的錯法是它判得出來的例子：這段查詢寫了外連接，而 WHERE 裡的星等條件是拒絕 NULL 的條件，補出來的列一列都留不住，結果與內連接在任何資料上都相同。這個等價由三值邏輯決定、與資料裡有什麼無關，所以最佳化器規劃查詢時自己就會用到它，MySQL 手冊把這一步叫 outer join simplification。最佳化器做這個改寫時不產生任何警告，要讀執行計畫才看得到：

 1-- 「不等於五」的錯法
 2EXPLAIN
 3SELECT 訂單.訂單編號 FROM 訂單
 4LEFT JOIN 評價 ON 評價.訂單編號 = 訂單.訂單編號
 5WHERE 評價.星等 <> 5;
 6-- 星等條件拒絕 NULL：補出來的列星等是 NULL，NULL <> 5 判成未知，全數被濾掉
 7-- PostgreSQL 16 印出 Hash Join：最佳化器已經把 LEFT JOIN 改成內連接
 8-- MySQL 8 的 SHOW WARNINGS 印出改寫後的查詢，連接寫的是 join
 9
10-- 正解
11EXPLAIN
12SELECT 訂單.訂單編號 FROM 訂單
13LEFT JOIN 評價 ON 評價.訂單編號 = 訂單.訂單編號 AND 評價.星等 = 5
14WHERE 評價.評價編號 IS NULL;
15-- 星等條件在 ON 裡；WHERE 的 評價編號 IS NULL 對補出來的列判成真，補出來的列留下
16-- PostgreSQL 16 印出 Hash Left Join：外連接保留下來

外連接被最佳化器改成內連接，代表查詢裡的 LEFT 沒有作用，而寫下 LEFT 的人要的正是保留沒有評價的訂單。

「NOT IN」的錯法是另一個例子，靜態分析在它身上判出來的是風險而不是確定的錯。風險由表結構與查詢文字兩處合起來決定，兩處都不必讀任何一列資料：

1-- 表結構：評價表的訂單編號沒有宣告 NOT NULL，這一欄可能是 NULL
2CREATE TABLE 評價 (評價編號 INT, 訂單編號 INT, 星等 INT);
3
4-- 查詢文字：NOT IN 的子查詢讀的正是那一欄
5SELECT 訂單編號 FROM 訂單
6WHERE 訂單編號 NOT IN (SELECT 訂單編號 FROM 評價 WHERE 星等 = 5);
7-- 子查詢只要交出一個 NULL，NOT IN 對每一列都判不成真，整段回零列
8-- 現有資料裡沒有訂單編號未填的評價，所以這段此刻回的仍是 102

靜態分析判不出「漏掉星等」：那段查詢與正解是同一種寫法，只差 ON 少了星等的條件，而查詢文字與表結構裡沒有任何一處說那個條件該在。

約束只讀寫入那一刻資料庫裡的資料，所以資料庫在寫入的那一刻就判得完。 約束是寫進資料庫、由它在每次寫入時檢查的規則，每一種讀的範圍由種類固定：NOT NULL 與 CHECK 只讀正要寫入的那一筆，UNIQUE 讀同一欄已有的值，外鍵讀它指向的那一列。NOT NULL 寫下「這一欄不會缺」，外鍵寫下「這個編號一定指得到一列」。讀的範圍超出這幾種的規則（「評價要在出貨之後」要讀另一張表的出貨日）同樣在寫入那一刻判得完，而要改用觸發器或應用層檢查。「NOT IN」的錯法要評價表裡出現一則訂單編號未填的五星評價才會回零列，而評價表的訂單編號那一欄若帶著 NOT NULL，那則評價一開始就寫不進來——這是「否定式一律用 NOT EXISTS」那條規則的豁免條件，不是對 NOT IN 展開方式那個誤解的修法。「不等於五」與「漏掉星等」寫不成約束：兩者錯在問錯了問題，而判斷一個問題有沒有問對要讀「要問的是什麼」，那不是任何一筆資料的性質。SQL.18 外鍵與參照完整性：宣告、生效與查詢得到的保證 拿參照完整性把約束走完一輪——外鍵擋下哪些寫入、宣告與生效在哪幾個位置分開，以及內連接掉列與 NOT IN 回零列這兩種錯各由哪一條約束管掉；五種約束各保證什麼在 Constraint（約束）。

要讀「要問的是什麼」的判斷交不出去，而提問的人的判斷可以記成一筆反例資料。 反例資料是一筆讓正解與某個錯的寫法回不同答案的資料，名字取自邏輯裡的反例（counterexample）：兩段查詢在某一筆資料上回的答案不同，就證明兩者不等價。上面三種錯法各有一筆——「不等於五」要訂單 101 再多一則非五星評價，「漏掉星等」要訂單 102 多一則非五星評價，「NOT IN」要一則訂單編號未填的五星評價。

反例資料從表的結構與查詢的條件推得出來，不必先知道哪一種寫法是錯的。 測試領域把這個做法叫等價類劃分（equivalence partitioning）：把輸入按程式對它的行為分類，每一類至少放一筆。落在這段查詢上，等價類是一張訂單配到評價的方式——一則都配不到、配到不只一則、配到的全部不是五星——再加上欄位是空值。沒有宣告約束的表全部允許這些等價類，而寫查詢的人容易當成它們不會發生；正解與錯的寫法對這些等價類的假設不同，所以兩者的答案就在這些等價類上分開。

一份把每個等價類各放進一次的資料，足以讓上面三種寫法各自交出不同的答案：

 1-- 從建好的空表開始；101、102 與 9001 同共用資料
 2INSERT INTO 訂單 VALUES (101,1,'2026-03-02',300), (102,1,'2026-03-09',500),
 3                        (103,2,'2026-03-10',200), (104,2,'2026-03-11',400),
 4                        (105,3,'2026-03-12',600);
 5INSERT INTO 評價 VALUES
 6  (9001,101,5), (9002,101,3),   -- 101：配到不只一則，其中一則五星
 7  (9003,103,3),                 -- 103：配到的全部不是五星
 8  (9004,104,5),                 -- 104：只配到一則五星
 9  (9005,105,4), (9006,105,2),   -- 105：配到不只一則，全部不是五星
10  (9007,NULL,5);                -- 訂單編號是空值的五星評價
11-- 102 一則評價都配不到
12-- 正解：102、103、105
13-- 「不等於五」：101、103、105、105（105 配到兩則非五星評價，出現兩次）
14-- 「漏掉星等」：102
15-- 「NOT IN」：0 列

提問的人要出的仍然只有一件事：這五張訂單裡哪幾張是答案。造得出反例資料，代表提問的人已經把「要問的是什麼」說到分得開兩個問題的程度；造不出來，代表兩段查詢在這張表結構允許的每一種資料上都回同樣的答案，兩種寫法等價、選哪一種都對。反例資料與「問對了沒有」交不出去並不牴觸：反例資料與它對應的正確答案仍然由提問的人給出，交給機器的只有比對這一步。

反例資料與約束改變的對象不同。 約束改變的是資料能長成什麼樣，不改變查詢——加上 NOT NULL 之後「NOT IN」的錯法不再回零列，是因為觸發它的那則評價寫不進來，而那段查詢照樣合法、照樣是同一個誤解，同一個人在下一個可為空的欄位上會再寫一次 NOT IN。反例資料不改變資料庫允許什麼資料，提問的人的判斷也仍然由他給出，改變的是那個判斷的保存形式：反例資料當輸入、他給的答案當預期值，合起來就是一則測試案例，往後每次改動那段查詢都能再跑一次，而讀者多半已經有跑測試案例的工具。反例資料只證偽、不證成——「漏掉星等」的錯法在原本那批資料上通過了一切檢驗，而通過從來不是對的證明。反例資料的射程另有一道邊界：它由提問的人依他當時對問題的理解寫下，所以它分得出「想的對而寫錯了」，分不出「想的就不對」。

反例資料與它的預期答案在測試領域有對應的名字，而測試那邊分得比本篇細：預期值從哪裡取得叫 test oracle，那張卡列了規格、參照實作、人的判斷與現狀四種來源，以及各自抓不到的那些；「寫斷言的人與寫實作的人共用同一份誤解」叫 test provenance；而「造不出反例資料」在 Mutation Testing 裡叫 equivalent mutant。本篇只講這三個概念落在 SQL 查詢上的樣子，三張卡各自涵蓋本篇沒有處理的情境。

正確性之外：查詢的代價與由引擎、資料庫決定的事

本篇之外還有一條與正確性互不覆蓋的軸：同一段查詢要花多久。一段查詢問對了沒有，與它要花多久，各自的判斷標準管不到對方，而代價那一層有一個機械的做法——向引擎要執行計畫。SQL.17 查詢的代價 量的是一道重複值的題目：加一個索引，最慢的那一種寫法就掉到與最快的同一個量級。

本篇處理的錯誤都發生在查詢的文字與提問的人之間：引擎照語意模型把結果算對了，而那不是要問的那一題。一段查詢的結果還受幾件不寫在查詢文字裡的事影響，它們由收下查詢的引擎與資料庫決定。同一段查詢合不合法，由執行它的那一家引擎判定，而標準禁止的寫法有的引擎照收、有的報錯，SQL.19 引擎寬鬆度與可攜性：各家對同一組寫法的差異、分級與處理時機 逐個寫法比較各家收不收、收了之後回什麼。查詢裡的表名與欄名送進引擎之後，引擎會照自己的規則處理大小寫與引號之後再去找對應的表與欄，SQL.14 識別字的規則：各家的大小寫摺疊、引號與保留字 寫各家的大小寫規則、引號的作用與保留字。執行查詢的帳號被授予哪些權限、最佳化器選了哪一個執行計畫、表上宣告了哪些約束、字串照哪一套 collation 比較，也各自影響同一段查詢回什麼，分別在 SQL.16 SQL 的權限模型：角色、GRANT 的授權單位與最小權限、SQL.1 宣告式的紅利與代價、SQL.18 外鍵與參照完整性：宣告、生效與查詢得到的保證 與 SQL.15 字串比較與 collation：相等、排序、LIKE 與索引可用性。

常見的幾種各自保證不同的事。NOT NULL 保證這一欄永遠有值；UNIQUE 保證這一欄的值不重複；PRIMARY KEY 是前兩者合起來再加上「這是本表辨識一列的依據」；FOREIGN KEY 保證這一欄的值在另一張表裡找得到對應的那一列；CHECK 保證這一欄滿足一個自己寫的條件（例如金額不為負）。

它決定哪些推論可以做

一個判斷標準能不能省掉某一步，取決於約束有沒有把那一步的前提固定住。最直接的一例是空值：NOT IN 在子查詢那一欄出現 NULL 的時候會整個回空集合而不報錯，所以否定式的成員判斷一般用 NOT EXISTS。這條規則有一個豁免——那一欄掛了 NOT NULL。豁免的條件是約束而不是觀察：翻遍現在的資料都沒有 NULL，只證明此刻沒有；約束證明的是往後也不會有，而查詢要活得比這一批資料久。

同一個結構在別處反覆出現：UNIQUE 讓「這個連接會不會讓一列配到多列」變成可以事先回答的問題（見 SQL.6 連接之後的列數與空缺：列數膨脹、外連接補的 NULL 與三值邏輯），FOREIGN KEY 讓「這個 JOIN 會不會掉列」有一個不必查資料就成立的答案。

概念位置

約束住在結構那一側，所以它由 DDL 建立與修改，而不是由日常的讀寫語句。這條歸屬有兩個後果：加約束的權限跟建表的權限走在一起，不跟常態運行的帳號走；加約束到一張已經有資料的表上會失敗，如果既有資料裡有違反它的那幾列。

它與索引在外觀上容易混——UNIQUE 在多數引擎底下確實靠一個索引實作，而兩者的責任不同：索引買的是查找速度，約束買的是內容的保證。刪掉一個索引查詢會變慢，刪掉一個約束則是往後的寫入不再被擋。

這條分工有一個邊界：約束宣告的內容同時是最佳化器可用的資訊，所以它買到的有時候多於內容的保證。同一張五千列的表、同一個 EXISTS 查詢、recordDate 上同樣掛著索引，只把索引從 UNIQUE 換成普通索引，SQLite 3.51.0 產出的位元碼就多一圈內層迴圈——唯一的時候引擎知道那次查找至多回一列，不唯一的時候它得準備好再看下一筆。這個差別在 EXPLAIN QUERY PLAN 上看不見，兩邊都印同一行 SEARCH y USING INDEX ix (recordDate=?)，要 EXPLAIN 到位元碼那一層才分得開；而在這組資料上它沒有量出時間差。同一組查詢在 DuckDB 1.5.5 上的計畫與有沒有 UNIQUE 無關。所以約束會不會影響代價是各家自己的決定，不是約束本身的性質（SQL.19 引擎寬鬆度與可攜性：各家對同一組寫法的差異、分級與處理時機）。

往下走

NULL 在比較、計數與分組裡各自怎麼表現，以及否定式那條規則的完整推導，在 NULL（空值） 與 SQL.6 連接之後的列數與空缺 的「子查詢含 NULL 時的 NOT IN 與 NOT EXISTS」一節。約束能在寫入時擋下哪些會讓答案錯掉的資料、為什麼問錯問題的那一類錯它擋不下，在 SQL.13 查詢的合法性與答案的正確性：引擎檢查的範圍、答案錯掉的成因與查證方法。FOREIGN KEY 擋下哪兩個方向的寫入、同一段宣告在各家引擎為什麼未必生效，在 SQL.18 外鍵與參照完整性：宣告、生效與查詢得到的保證。約束由誰有權建立、以及它跟常態運行帳號的權限為什麼分開，在 SQL.16 SQL 的權限模型：角色、GRANT 的授權單位與最小權限。

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

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

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

外鍵擋下的寫入與 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 引擎寬鬆度與可攜性：各家對同一組寫法的差異、分級與處理時機。