AI 說驗證做好了，究竟是哪一層？
What does “validation is done” actually mean?
AI 跟你說「驗證做好了」，到底是哪一種驗證好了？現在和 AI 一起做系統，很常出現這種對話 ：Email 有檢查不能重複嗎？ 「有，已完成驗證。」 ：電話有設定必填嗎？ 「有，已加入驗證。」 ：刪掉會員會不會影響其他資料？ 「已處理。」
看起來什麼都有。
但問題是「它到底把規則做在哪裡？」 因為畫面上「不讓你按下一步」、程式收到資料後「幫你檢查一次」，和資料庫本身「根本不允許這種資料存在」，其實是三件不一樣的事情。你可能完全感覺不出差別，更可能是一切都很好按鈕正常、表單正常、Demo 也跑得超級順。
當有一天資料不是從原本那個畫面進來，例如管理後台、API、CSV 匯入甚至某天又叫 AI 幫你批次修改資料，原本那一層驗證可能根本都不會經過。 然後你才發現同一個 Email 居然出現兩個會員？！一筆報名紀錄居然指向一個根本不存在的課程！？某個理論上必填的欄位，居然被允許可以是空的！？
詭異的地方就在程式不是不能跑，甚至跑得很好，這反而是最危險的，因為你以為已經被保證的規則，其實從來沒有真的被保證過。
– 我是分隔線 – 現在你有一棟陶朱隱園(?)
你可以在牆上貼一張「陌生人請勿進入」 也也可以把規則做在門上「沒有門禁卡，門就是不會開」。前者是在提醒大家不要犯錯，後者是讓某些錯誤根本沒辦法發生。我想你應該不希望任何人都可以進出你的陶朱隱園？
那恭喜你資料庫裡有一類設計就是在做後面這件事情，它叫 Constraint，中文常翻成「約束」，但名字其實不是最重要的，你可以忘記它了 (?)
重要的是哪些事情是你的系統不管從哪個入口進來，都不應該允許它的？（限制小偷無論哪個入口都不能夠進去）
例如： 我不希望系統搞不清楚我到底在改哪一筆會員。 我不希望一筆報名紀錄，指向一個根本不存在的會員。 我不希望同一個 Email 被註冊兩次。 我不希望訂單金額出現 -500 元。
這些都不是「提醒一下就好」的事情，如果真的發生，代表資料本身已經壞掉或是有問題了，會是發生當下最迫切需要解決並止損的問題。（通常過去也會有幾筆資料也是壞的，要記得過去的一起檢查過哦）
那資料庫到底要怎麼把這些規則「做到門上」？其實做法很多，我收斂成幾個常見問題來快速理解它們。
第一個問題：如果系統裡有兩個都叫王小明的人，你要怎麼確定現在改的是哪一個？
名字顯然不夠，電話可能會換，Email 也可能改。所以通常每一筆資料都會有一個穩定而且不重複的識別。例如：會員 10001、會員 10002、會員 10003 這個編號很多時候不一定有什麼商業意義，它就只是系統拿來認人的，這東西叫 Primary Key 主鍵。
你可以先把它理解成「我一定要能很明確地指出，我現在講的是哪一筆資料。」 不然有一天就會發生你跟 AI 說：「幫我修改王小明。」 AI 回頭看了一下：「哪一個王小明？」 反而實際情況是 AI 問你是哪一個還是相對理想的，因為 AI 更多時候會直接有他的判斷，到最後出問題時才發現，並且誠懇的和你說拍謝。
在真實世界中，只有「知道這筆是誰」還不夠，資料庫裡很多問題，不是單筆資料本身出錯，而是兩筆資料之間的「關係」壞掉。 例如你有： members（會員） bookings（報名紀錄） 有一筆 booking 上面寫著：member_id = 1234。那你真正要確認的是「1234 這個會員，真的存在嗎？」如果不存在，這筆報名到底算誰的？所以資料庫可以直接幫你守一個規則：「你如果說這筆報名屬於會員 1234，那會員 1234 就必須真的存在。」
Foreign Key 外鍵，它就是專門來處理這種關聯的，可以把它想成掛號單上的病歷號，掛號單上不能隨便寫一個不存在的病歷號，然後假裝這個病人真的存在。
有關聯很單純，但真正麻煩的是如果這個會員後來刪掉了不見了，那原本跟他的資料怎麼辦？ 例如會員 1234 被刪掉了。那他的掛號紀錄或是報名紀錄呢？ 這時候沒有標準答案，反而會取決於你要幹嘛
你可能規定「下面還有報名紀錄，所以先不准刪這個會員」 也可能規定「會員刪掉時，某些相關資料一起處理」 也可能是「紀錄留下來，但不再連回原本那個會員」 怎麼決定端看你的業務到底希望發生什麼事？
像是「會員刪掉之後，他過去的訂單要不要一起消失？」，我通常不會第一時間回答：「全部刪掉就好。」因為訂單可能還牽涉付款、發票、客服查詢、稽核，甚至法律或會計上需要保留的歷史資料。往往真正想做的不是把這個會員整筆刪掉，而是停用帳號、刪除或匿名化部分個資，同時保留必要的交易紀錄。（普遍情況留下紀錄比較好，除非你有明確需求知道自己為何而刪）
需要想清楚兩筆資料之間是什麼關係，以及其中一邊消失時，另一邊應該發生什麼事？ – 快讀完了!!! –
理解完「這筆是誰」和「它跟誰有關」之後，最後這個使用情境更貼近日常了。有些規則其實很像我們平常填表單會遇到的限制...... 像是現在超過字數限制啦！我們留言見 <3