如果我有一個表叫university
,有兩個字段,一個爲id_university
,也就是PK和其他name_of_university
。大學的每個名稱都是獨一無二的,不能重複。更改我在表中的PK
在這種情況下,我可以刪除id_university
,並將name_of_university
作爲主鍵,是否正確?
事情是這樣的:
表
university
-----------------------
pk name_of_university
感謝
如果我有一個表叫university
,有兩個字段,一個爲id_university
,也就是PK和其他name_of_university
。大學的每個名稱都是獨一無二的,不能重複。更改我在表中的PK
在這種情況下,我可以刪除id_university
,並將name_of_university
作爲主鍵,是否正確?
事情是這樣的:
表
university
-----------------------
pk name_of_university
感謝
你可以做到這一點,但你不應該。大學的名稱是商業關鍵,因此可能會發生變化。確定候選主鍵的標準之一是它們應該是不變的。
因此,最佳實踐是擁有代理(合成)主鍵,用於外鍵等,並對業務鍵保持唯一性約束。所以,好消息是,您目前的數據模型已接近最佳實踐。只需在名稱欄中添加一個獨特的名字,您就可以輕鬆前往。
alter table university
add constraint uni_name_uk unique (name_of_university);
這是很好的做法,離開主鍵id_university
,只是加上name_of_university
唯一索引。
是的。
但不推薦。
長時間的PK讓所有的事情緩慢下來。
而在InnoDB上,PK包含在中,每個二級密鑰,這會使你的表膨脹。
Join的速度會變慢,插入速度會變慢,排序會變慢。
而你的桌子會更大。 這是一個非常糟糕的主意:--Sorry
保持你的PK儘可能短和自動增量(如果可能),這將導致活潑快樂的代碼。
是的,這是正確的。一把鑰匙是一把鑰匙。如果您擁有多個密鑰,那麼您將其稱爲主要密鑰的密鑰並不重要。重要的是你打算實施和使用它們的方式。
候選鍵應該是穩定的,不一定是不可變的。除非你的dbms不支持'ON UPDATE CASCADE'。 – 2011-05-08 19:53:23