用sql server設計了一個表，其中有一個人的身份證的信息，我想以身份證號爲主鍵，可以嗎？
可是網上看到的資料說，主鍵不應該人爲給定的，應該由計算機自動生成，貌似就是自增的意思。
可以用身份證號碼作爲主鍵，反正不會出現衝突就好了。
網上的說法，或許只是建議使用自增列作爲主鍵。
遇到一個結論，思考一下爲什麼。各種方案，只要是可行的，便沒有對錯，只有優劣。自己理解了，才能根據自己的情況靈活選擇。
主鍵：邏輯概念。一個主鍵唯一地決定表中的一條記錄。一個表只能有一個主鍵。
聚集索引：物理概念。聚集索引決定表中數據的物理存儲結構，同時也是最高效的查詢途徑。一個表只能有一個聚集索引。
通常主鍵會默認爲聚集索引。但這不是必須的。主鍵和聚集索引是兩回事，一定分清楚。
選擇自增標識列或GUID爲主鍵
優點：1. 可由計算機自動生成，方便。2. 定長字段，而且通常爲整數，佔用空間小。
缺點：缺乏直觀的意義，只能作爲系統內部的標識。
示例：ERP系統的訂單號、BBS系統的用戶號和帖子號。
選擇預定義編碼爲主鍵
優點：編碼具有直觀意義，方便使用。
缺點：1. 編碼需要專門生成和維護。2. 有意義編碼通常是字符串類型，佔用空間較大。
示例：公安部國民信息系統的身份證號、郵政系統的郵編號、電信系統的電話號碼。
選擇思路
1. 如果一個表的數據量和數據變化不大，使用頻率高，且不需要太多索引（聚集索引鍵影響非聚集索引的空間大小），則考慮選擇預定義編碼。
如員工工號、部門編號，使用E0001、D1-2的編碼就比使用12345、67890這樣的標識列更直觀、易用。
如日曆表顯然是以日期爲主鍵，號段地區表顯然是以號段爲主鍵，這種情況下添加一下自增標識列完全吃力不討好，既浪費空間又降低性能。
2. 如果一個表的數據是在業務運行中不斷生成，數據量和數據變化比較大，或者需要建多個索引，則考慮使用內部定義主鍵（標識列）。
如ERP系統的訂單號，專門編制有意義的編碼既費力又沒有意義。
如圖書館系統或網上書店的圖書表，往往採用內部定義主鍵（整數標識列），使用ISBN固然可以，但由於圖書需要多種查詢方式，需要在書名、作者、出版社+出版年、ISBN等多個字段上建索引，如果主鍵太大會浪費空間影響性能。
選擇主鍵（以及聚集索引），不光要從技術上考慮，也要從系統業務角度考慮。
從邏輯上說，一個表是一種事物（事或物的統稱）的集合，一個主鍵即是一個該類事物的唯一標識。
如果要表示一個國家的人，以身份證號（社會保險號等）作爲主鍵是必然。
如果要表示世界上的人，則需要以國家碼+該國國民身份編號作爲主鍵。
如果只是表示一個企業的員工，用身份證號則不太有必要，不如制訂一個企業內部員工編號。但設計編碼要考慮業務變化和未來兼容性，比如當兩個企業合併以後，員工編號要怎麼處理。
全國身份證號是有重複的，不能作爲主鍵，不用懷疑身份證號沒有重複的啊，可以用來做主鍵!
身份證號有重複？除非是造假吧。
支持做主鍵，不過要看你的實際需求，表的結構。
LZ說說的自增的是設置了標識列 作爲標識列後就能自動增長 比如標識種子是1 標誌增量也是1那麼你插入的數據ID自動生成就一次爲1 2 3 ...
身份證號碼可以作爲主鍵 因爲身份證號是唯一的
主鍵可以由一個字段，也可以由多個字段組成，分別成爲單字段主鍵或多字段主鍵。
來源：足球直播
