小議“外鍵”

是一幅很普通的外鍵關係樣本，途中stu代表一個學生，category代表為學生建立的一個分類如：大學生、小學生、初中生。如果stu中的category_id不允許為空白，那麼在出入stu記錄前必須保證此category_id 的存在，這個我想誰都沒有問題。那麼插入stu前該做哪些事情呢，必須知道當前的stu屬於那個類別，如果category_id可以為恐則不需要這麼做，換句話說插入stu記錄中凡是有category_id的記錄必須先做檢查，如果此category不存在要先插入。

這個時候另一個問題出來了，有的人說插入了category但是不知道它的id，因為id是由資料庫自動維護的。其實這個根本不是問題，它是另一個問題的表象。因為id是用來標識一張表的，而實際上category的名字也是用來唯一標識，準確的說id是次要的。我們把上邊這張表完全可以簡化為一張表，也就是帶category_title的stu表，如果只是一個欄位那麼冗餘度沒那麼高，當欄位多了，冗餘度就非常高了，為了降低冗餘度但又不破壞資料的關係，所以才有了上面兩張表的格局，這個時候我們唯一冗餘的就是一個32位的整型欄位，忽略不計。當然有人提出了更好的、代替32位整型的資料類型作為id,在此我們不做累述。那麼回到剛才的問題，插入了category後是不知道當前插入了記錄的id（如果你說按時間查詢，首先這很蠢，而且沒道理，我相信大部分人不會這麼幹，比如有很多並發請求的時候可能查詢出的是別人的記錄。），但是有stu的記錄，根據stu查出它的類型，然後儲存，說的詳細點，也就是說出這個問題的人是在設計上出現了問題。