上圖是一幅很普通的外鍵關系示例，途中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查出它的類型，然后存儲，說的詳細點，也就是說出這個問題的人是在設計上出現了問題。

總結

以上是生活随笔為你收集整理的小议“外键”的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。