Primary key、Serial Number、ID
以上這些稱呼，可能都指的是同一個東西，也就每個資料表 Table 中不可或缺的「主鍵」。
主鍵具有「不重複性」，提供每一筆記錄的唯一參考値，做爲與其他資料表 Table 建立關係時候的一個依據。這樣說可能還是有點複雜，我們可以把主鍵想像成一筆記錄的「身分證字號」，不可能重複，而資料庫可以運用這個字串的特性來做各種連結，就不會出現重複所產生錯誤。
這邊用的稱呼是「字串」而非「數字」，原因是主鍵通常是文字+數字的複合體呈現。當然也可以全是數字，會因爲每個開發者所習慣的方式不同，而有不同的作法。
我自己接觸過的 Primary key (id) 有三種，分別介紹如下：
-
Primary key (id) 第一型：
傳統的作法，就是採用 Serial Number 固定加 1 的方式，比如第一筆記錄就是 1，第二筆記錄是 2，第三筆記錄是 3，……，第 100 筆記錄是 100，依此類推：1, 2, 3, ……, 100
-
Primary key (id) 第二型：
承襲第一種作法，但稍微有點變動，把 Invoice Table 裡面的 id 加上前綴 INV，後面在接上 Serial Number，第一筆記錄變成 INV000001，第二筆記錄是 INV000002，第三筆記錄是 INV000003，……，第 100 筆記錄是 INV000100，依此類推：INV000001, INV000002, INV000003, …… , INV000100
-
Primary key (id) 第三型：
完全跳脫第一種根第二種 Serial Number 的作法，直接賦予一個全新的 UUID (Universally Unique Identifier 通用唯一識別碼)，通常我們會採用 Get (UUID) 的方式來自動取得這樣的一個 id，這個 id 的樣子通常會長成下面這樣：
46425955-B942-4C9F-B2AE-BDD0D2B82BA2
依照「8碼 – 4碼 – 4碼 – 4碼 – 12碼」的字母數字不規則排列，可以想像重複的機會就變得非常非常小。
以上三種不同的 Primary key 安排方式，基本上就是希望避免 id 重複出現的程度，第二種 Serial Number 比第一種安全，第三種 UUID 又比前兩種來的更加安全。
UUID 在現今行動網路的時代更容易被接受，因爲這樣的方式可以確保離線後同步資料能更加正確，所以還是建議採用這樣的方式來開發資料庫，這樣不管是正確性、通用性都將會更好。
FileMaker 小子 