資料庫主鍵不應該具有任何業務意義

        關聯式資料庫學的最重要的一個理論是：不要給關鍵字賦予任何業餘意義。假如關鍵字具有了業務意義，當使用者決定業務含義，也許他們想要為關鍵字增加幾位元字或者把數字改為字母，那麼就必須修改相關的關鍵字。一個表中的主關鍵字有可能被其他表做為外鍵。就算是一個簡單的改變，也可能會造成極大的維護上的開銷。
        為了使表的主鍵不具有任何業務意義，一種解決辦法是使用代理主鍵，例如為表定義一個不具有任何業務含義的ID欄位（也可以叫其他名字），專門做為表的主鍵。
        我回顧我以前設計的很多資料庫，都在某些地方沒有考慮周到，即使大部分的主鍵都沒有業務意義，還是會有某些表的主鍵和業務聯絡起來。因為我一直認為，主鍵是用來保持唯一性的，之所以要有代理主鍵，是因為有一些記錄的內容沒辦法保持唯一性。例如設計一個使用者表，使用者的名字有可能重複，這個人可能叫blue，那麼人也可能叫blue。這樣就需要一個ID來分清。
        由於我之前的想法，導致我資料庫設計上的一些錯誤。例如我曾經在一次資料庫設計中使用一個ID來做為一個表的主鍵，該表是記錄一些報表的。每個報表上都有一個ID，這個ID是具有業務意義的，是可以讓客戶輸入，也可以自動產生的，但是客戶說明這個ID是唯一的，是數字類型。因此由於它的唯一性，我在資料庫中設計這個ID為數字類型的。但是到了後來客戶要求使用文字類型的，例如原來的是“111111”，他要求可以寫成“11111A”，“11111B"。這個時候由於這個ID做了很多表的外鍵，就會產生很多維護上面的麻煩。即使在資料庫表之間做了串聯更新和串聯刪除，修改資料類型還是很麻煩的事情。
        這次RFID項目資料庫設計我原來想使用RFID標籤的ID做為產品的主鍵，因為RFID標籤ID具有唯一性，使用它作為主鍵在尋找的時候速度應該會快些。但是後來發現問題並不是這麼簡單。如果使用RFID標籤ID做為主鍵，那麼就具有了業務意義。當產品表和其他表關聯，產品表的主鍵做為其他表的外鍵的時候，如果出現一些業務上的情況，例如RFID標籤壞了，要更換，就會產生更改主鍵內容的問題了。
        回顧一下，還是發現自己的基礎不紮實。學習資料庫的時候都不去上課。少年不努力，老大徒悲傷。