用sql server設計了乙個表，其中有乙個人的身份證的資訊，我想以身份證號為主鍵，可以嗎？
可是網上看到的資料說，主鍵不應該人為給定的，應該由計算機自動生成，貌似就是自增的意思。
可以用身份證號碼作為主鍵，反正不會出現衝突就好了。
網上的說法，或許只是建議使用自增列作為主鍵。
遇到乙個結論，思考一下為什麼。各種方案，只要是可行的，便沒有對錯，只有優劣。自己理解了，才能根據自己的情況靈活選擇。
主鍵：邏輯概念。乙個主鍵唯一地決定表中的一條記錄。乙個表只能有乙個主鍵。
聚集索引：物理概念。聚集索引決定表中資料的物理儲存結構，同時也是最高效的查詢途徑。乙個表只能有乙個聚集索引。
通常主鍵會預設為聚集索引。但這不是必須的。主鍵和聚集索引是兩回事，一定分清楚。
選擇自增標識列或guid為主鍵
優點：1. 可由計算機自動生成，方便。2. 定長字段，而且通常為整數，占用空間小。
缺點：缺乏直觀的意義，只能作為系統內部的標識。
示例：erp系統的訂單號、bbs系統的使用者號和帖子號。
選擇預定義編碼為主鍵
優點：編碼具有直觀意義，方便使用。
缺點：1. 編碼需要專門生成和維護。2. 有意義編碼通常是字串型別，占用空間較大。
示例：公安部國民資訊系統的身份證號、郵政系統的郵編號、電信系統的**號碼。
選擇思路
1. 如果乙個表的資料量和資料變化不大，使用頻率高，且不需要太多索引（聚集索引鍵影響非聚集索引的空間大小），則考慮選擇預定義編碼。
如員工工號、部門編號，使用e0001、d1-2的編碼就比使用12345、67890這樣的標識列更直觀、易用。
如日曆表顯然是以日期為主鍵，號段地區表顯然是以號段為主鍵，這種情況下新增一下自增標識列完全吃力不討好，既浪費空間又降低效能。
2. 如果乙個表的資料是在業務執行中不斷生成，資料量和資料變化比較大，或者需要建多個索引，則考慮使用內部定義主鍵（標識列）。
如erp系統的訂單號，專門編制有意義的編碼既費力又沒有意義。
如圖書館系統或網上書店的圖書表，往往採用內部定義主鍵（整數標識列），使用isbn固然可以，但由於圖書需要多種查詢方式，需要在書名、作者、出版社+出版年、isbn等多個欄位上建索引，如果主鍵太大會浪費空間影響效能。
選擇主鍵（以及聚集索引），不光要從技術上考慮，也要從系統業務角度考慮。
從邏輯上說，乙個表是一種事物（事或物的統稱）的集合，乙個主鍵即是乙個該類事物的唯一標識。
如果要表示乙個國家的人，以身份證號（社會保險號等）作為主鍵是必然。
如果要表示世界上的人，則需要以國家碼+該國國民身份編號作為主鍵。
如果只是表示乙個企業的員工，用身份證號則不太有必要，不如制訂乙個企業內部員工編號。但設計編碼要考慮業務變化和未來相容性，比如當兩個企業合併以後，員工編號要怎麼處理。
全國身份證號是有重複的，不能作為主鍵，不用懷疑身份證號沒有重複的啊，可以用來做主鍵!
身份證號有重複？除非是造假吧。
支援做主鍵，不過要看你的實際需求，表的結構。
Java基礎 乙個死鎖問題
package cn.itcast 02 public class mylock package cn.itcast 02 public class dielock extends thread override public void run else package cn.itcast 02 同...
組合問題乙個
100可以表示成多少個正整數之和？f m,n,p 表示n個不小於p的正整數之後為m的組合數 則顯然有邊界條件 f m,n,p 1,當n 1且m p f m,n,p 0,當mf m,n,p sum f m i,n 1,p i i 0 p i m i,m i n 1 若f m 表示m可以表示成若干正整數...
乙個小問題
error c2679 binary no operator defined which takes a right hand operand of type class smanip int or there is no acceptable conversion 除錯了好久，就是找不出問題在哪。...