我應該在這裏使用主鍵嗎？

舉個例子，我有3個表：我應該在這裏使用主鍵嗎？

School: ID int, Name varchar 

Student: ID int, Name varchar 

StudentInSchool: StudentID int, SchoolID int

現在的問題是我是否應該把一列ID int在StudentInSchool表上有一個主鍵？如果是，爲什麼？

會不會是在索引有幫助嗎？

任何幫助表示讚賞。

來源

2010-01-22 Manish

就我個人而言，我在這樣的junction tables上創建複合PK（StudentID和SchoolID）。這也確保了獨特性。

但如果不是必需的獨特性，你必須添加一個ID列唯一標識每一行。

一般來說，除了單獨ID列的幫助不大：極少數的查詢（如有）將實際使用此列。至於性能，你可以爲每一列創建單獨的索引，你會很好。

來源

2010-01-22 10:28:10

+1。我採用相同的方法 – Alex 2010-01-22 10:29:52

取決於我們想要使用聯結表來描述的關係的基數。當我們嘗試建模現實世界時，強制一對一關係可能會適得其反。 – 2010-01-22 10:31:18

在StudentID, SchoolID上創建一個主鍵，在SchoolID上創建一個二級索引，反之亦然，具體取決於更經常使用的搜索條件。

如果你的表是索引組織（ORGANIZATION INDEX在Oracle中，CLUSTERED在SQL Server，InnoDB在MySQL），然後二級索引將有一個PRIMARY KEY作爲最左邊的部分，因此，所有的信息可以獲取列的索引。

來源

2010-01-22 10:30:54 Quassnoi

答案是，這取決於。在大多數情況下，答案是「否」：(StudentID, SchoolID)的複合主鍵就足夠了。

但是，如果該交點表開始獲取其他相關數據（比如加入日期，離開日期）和/或它成爲相關表格的父項（例如出席記錄），那麼您可能需要或需要將其視爲定期表。在這種情況下，(StudentID, SchoolID)成爲商業密鑰（即仍然是唯一的），並添加Id或其他合成（或代理）主鍵。

來源

2010-01-22 10:31:57 APC

就純數據完整性而言：無。將主鍵定義爲（StudentID，SchoolID）是完全足夠的。

但是，你不說你正在使用的RDBMS。可能對於其中的一些，單個ID列會導致更高效的查詢計劃。

在SQL Server的情況下，兩個整數的組合主鍵是非常有效的，並且沒有進一步的索引應在兩列是必需的。

來源

2010-01-22 10:31:59

在這個例子中，除非StudentInSchool表格要具有其他屬性，例如，學生在該學校應對動作時的時間戳，我不會使用它，我會將schoolID字段放在Student表中，並將其定義爲外鍵。

但是，如果這是設計，那麼是的，通過在StudentInSchool表上放置一個主鍵，你不會失去任何東西。

來源

2010-01-22 10:31:57 Unsliced

您可以結合StudentID和SchoolID一個主鍵。

描述何時使用索引有一些通用規則。當處理相對較小的表時，索引不會提高性能。在中，一般索引在表連接中使用的字段上創建時提高了性能。使用索引時，數據庫查詢的大多數檢索相對較小的數據集，因爲如果大多數時間您的查詢檢索大部分數據，索引將實際上減慢數據檢索。使用索引用於具有許多不同值的列（列中不存在多個重複值）。儘管索引提高了搜索效果，但它們減慢了更新速度，，這可能是值得考慮的事情。

來源：SQL Indexes

來源

2010-01-22 10:34:33

好吧，我覺得有東西在分配丟失，所以我會與我的現實世界的知識貧乏嘗試：O）

什麼是學生？他們上學，他們可能在一所以上的學校（尤其是大學）學習，他們甚至可能會在以後再學同一所學校等。

交叉表原樣（在兩個ID上都有PK）足夠多模擬這些關係？

簡短的回答：沒有

長的答案：還沒有，但對於簡單的情況下，子集就足夠了（你是他們中的一個？）。

如果您想在所有這些情況下延遲db，則需要代理PK（您的ID）。如果我只是懷疑它可能是必需的，我會把ID放在那裏（因爲沒有太多可能會丟失）。

正如第一句所述 - 正確答案是：「我們不知道」，因爲缺少應用程序的要求和上下文。

來源

2010-01-22 12:42:58 MaR

我應該在這裏使用主鍵嗎？

回答

相關問題