主鍵應該是什麼？

我碰到，我似乎無法來解決的問題。主鍵應該是什麼？

例如說，我與即將到來的視頻遊戲發佈的表：

GAME 
game_ID | title    
----------------------------- 
1  | Super Mario 
2  | Final Fantasy XIII

然後我有一個表releasedates（不同日期PS3和XBOX360只是爲參數的緣故）：

RELEASES 
game_ID | releasedate | platform 
--------------------------------- 
1  | 20-04-2010 | Wii 
2  | 23-03-2010 | PS3 
3  | 20-03-2010 | Xbox360

現在，我已經把game_ID作爲主鍵在表格「GAME」中。而game_ID也是表「RELEASES」中的外鍵。作爲後者的主鍵，我應該有什麼？似乎沒有必要在「RELEASES」表中創建另一個ID鍵--table？

我可以以某種方式使用game_ID和平臺共同打造的主鍵？如果是這樣，SQL將如何？

來源

2011-05-23 Marcus

就像你創建一個僅包含一列的主鍵，您可以創建一個包含game_id和platform複合鍵：

PRIMARY KEY(game_id, platform)

來源

2011-05-23 13:00:44

作爲這麼簡單，是吧？ =）是否有使用複合鍵的任何缺點？ – Marcus 2011-05-23 13:04:27

沒有技術缺點。我能想到的唯一缺點是在Steve Mallory和Paul Alan Taylor的回答中提到，但在我看來，這是根據具體情況決定的...... – 2011-05-23 13:17:13

你不想game_ID作爲主鍵和外鍵在發佈表中。這會阻止表格爲每個遊戲創建多個記錄，因爲主鍵必須是唯一的。我會推薦一個這樣的結構。

RELEASES 
release_ID | game_ID  | releasedate | platform 
--------------------------------------------- 
    1   |  1  | 20-04-2010 | Wii 
    2   |  1  | 23-03-2010 | PS3 
    3   |  1  | 20-03-2010 | Xbox360

release_ID將自動生成。您可以通過在主鍵中包含平臺來使用複合鍵，但如果單個遊戲/平臺具有多個版本，則可能會遇到問題。你現在可能不認爲這是可能的，但事情會改變。

我也認爲從不使用具有任何意思作爲關鍵的列的良好做法，因爲事情會發生變化，您無法預測它們將如何變化。如果你的密鑰對最終用戶沒有意義，那麼他們不能混淆你數據庫的結構。

來源

2011-05-23 13:08:01

它有一個帶有game_id和platform的組合鍵，所以每個遊戲都可以在多個平臺上進行多次啓動。然而，我投票贊成，因爲我同意添加release_id作爲PK – 2011-05-23 13:13:51

@Tudor我在主鍵（game_id，platform）上的問題是在** same **平臺上的多個版本，雖然現在可能不是問題，可能會在未來。 – 2011-05-23 13:20:19

該案例可以通過向組合鍵添加發布日期來解決 - 但這並不好， – 2011-05-23 13:22:23

首先，考慮實現平臺作爲一個單獨的查找表。這不僅可以減少數據損壞的可能性，還可以使您的密鑰定義更加簡單。

主鍵不必被限制爲一個字段。您可以使用多個字段定義複合主鍵。

但是，在這種情況下，我建議不要使用複合主鍵，並且會主張在Releases表上創建一個新的主鍵。

爲什麼？那麼，對於初學者來說，我認爲你沒有在發佈中獲得足夠的信息。例如，視頻遊戲通常在不同地區的不同時間發佈，因此在同一遊戲和平臺上發佈兩個版本可能是完全有效的。在這種情況下，您需要一個由三個字段組成的複合主鍵。它在哪裏結束？ :)

通過將ReleaseID定義爲代理主鍵，您將給自己更多的空間進行更改。

來源

2011-05-23 13:13:42

主鍵應該是什麼？

回答

相關問題