AI 做的資料庫，如何替作品把關？
How to review an AI-generated database
以前系統最擔心的是「程式要怎麼寫？」，現在反而變成另一個問題是，AI 幫我做出來的東西，到底對不對？
一個 Prompt 下去，咻～蹦！ 一份完整的資料庫設計就生出來了，甚至直接能動能運作，也動得很好。 （資料庫不是和ＡＩ詠唱就會跑出來的東西，之後和大家分享資料庫差異，還有怎麼選）
但是能動和能撐三年，是兩件事。
很多系統問題沒壞在第一天，而是壞在半年後。因為資料開始累積、需求開始改、新功能開始加。直到某一天，你只是想新增一個功能，卻發現整個資料庫像一間塞滿雜物的倉庫，也不知道該怎麼和 AI 描述。東西可能不會找不到，但每個地方都有還不一樣，這就是開始失控的起點。
- 我是分隔線 -
你可以這樣理解，如果開了一間店，開幕第一天，貨都隨手堆也能做生意，反正東西不多你全都記得放在哪。那三個月後呢？同一款商品散在五個角落，標價還不一樣。客人問還有沒有貨，你得繞整間店找一圈才敢回答，或是你要賭他不會發現（請不要這樣）
資料庫設計其實就是在做這件事：在把東西放進去之前，要先決定貨架怎麼排？ 亂放好像也還好，反正動得瞭就好？這才是危險的地方，通常出事時東西已經堆滿整間倉庫，從哪裡開始整理都不知道。
學資料庫就會學到一個概念叫「正規化」 如果先不管那些複雜定義或是有第幾正規化，可以先把它理解成：
「同一個會持續變動的事實，最好只有一份。」
像是朋友的電話號碼你只記在通訊錄裡，如果他有換號碼你改一次就好，但如果你是把電話抄在十本筆記本上（可能一直弄丟筆記本？），有一天他換號碼了，你七八本都更新完資訊了，但下次翻開筆記本好死不死就翻到你沒改到的那一本，打不通又浪費時間。
那有例外嗎？都會是Ａ改Ｂ就一定得要跟著改嗎？ 拿開發票來說好了，發票印出去之後商品漲價，總不會要回頭補收客人的錢吧，所以「訂單」的價格不會一定是重複資料要完全一樣，而是刻意保留下來的「歷史快照」。「現在的狀態」和「當時的事實」，是兩件不同的事情。
分得清這一點，你就開始站在資料設計的角度思考，而不是只是在存資料。
- 你快讀完了...... -
如果你用 AI 做了某個東東，而 AI 幫你把資料表生出來之後，就算你沒學過資料庫，也能快速檢查它有沒有明顯問題。先從我來講，我自己會先看三件事：
第一件｜看表的名字。 假設你請 AI 做一個課程報名系統，它給了你三張表： 1. members（會員） 2. courses（課程） 3. bookings（報名）
我們先不要急著看欄位，先表的看名字，每一張表都應該能對應到現實世界的一個名詞。像是會員、課程和報名等等的，那什麼叫做對應不了？如果 AI 生出一張叫 data_records、system_data 或 potato_data 的表，你就要停下來看：「這張表到底在幹麻，對應了現實世界中的什麼？」。如果 AI 給你的答覆很含糊，要嘛回去看是不是你前面提的需求不夠明確，還是 AI 真的在那個傍晚降智了 (X)
第二件｜找重複 什麼重複？這三張當中有兩張表可能 members 裡有電話 bookings 裡也有電話 重複沒有不對，有時候本來就會都存到是正常的，但是要去確認 AI 知道一件事，如果今天會員改電話號碼，要改幾個地方？
如果答案是兩個，那很好沒問題，還可以再追問：bookings 裡這支電話，到底代表什麼？
如果 bookings 想表示的是「這位會員現在的電話」，那其實不用再存一份電話。只要記住「這是誰報名的」（members 裡面有紀錄了），需要電話時再回會員資料找就好，這樣會員換電話時只要改一個地方，所有地方看到的都會是最新資料。
所以重點重複沒有不對，而是你到底想記錄什麼？紀錄在那邊幹嘛？
第三件｜看哪些重複是刻意留下來的？ 像是課程價格，課程漲價了，已經報名的人要補錢嗎？（理論上不會(?)） 所以報名紀錄上的價格，就應該停留在當時。這種重複就沒有不好，它純粹就是「歷史」。
你會發現同樣都是重複資料。一個是未來可能的地雷（改了Ａ但發現Ｂ顯示舊資料沒被改到），另一個卻是刻意保留下來的重要資訊（歷史，或是這裡講的訂單紀錄 or 發票）。
判斷的方法不用想得很複雜，你就想這個資訊如果未來改了，這裡應不應該跟著改？
要？ 那通常不要複製 （是通常不是一定哦，資料庫不是二分法，很多東西都不是）
不要？ 那留下快照，就是合理的設計（歷史）
所以我現在在檢查 AI 資料庫通常就是三步： ① 表名翻譯得回現實嗎？ ② 找出重複的資訊 ③ 判斷它到底是地雷還是歷史快照？
你也不用寫任何程式，可能十分鐘就能抓出 AI 最容易犯的一大類問題 （但如果你架構超複雜，一個 prompt 就一堆東西另當別論......）
居然有限字數，後面內容詳見留言🤝🥷🏿