代理鍵與複合鍵

對數據庫模式的相當新穎（計劃使用SQLite）。話雖如此，我正在考慮使用代理鍵，因爲數據庫當前包含一個複合鍵（3列），它出現在我的大部分表中。我有幾個表，其中包含3列的唯一鍵和一列包含一些信息;我也有一個表包含3列的唯一鍵和相同的3列作爲外鍵（許多父母）。將所有這些表合併到一張表中似乎沒有意義，因爲會有許多空的字段。代理鍵與複合鍵

如果我選擇其中一個，任何坑都會掉下來？通常認爲哪一種編程更方便？

預先感謝您。

來源

2011-10-24 jobobo

每種技術都有優點和缺點。

通常，如果您只需引用單個代理鍵列，則編寫SQL語句和JOIN會更容易。它也大大減少了數據庫的大小。

另一方面，使用代理鍵時，您經常發現自己不得不向您的JOIN添加至少一個額外的表，以便檢索屬於代理鍵的信息。代理鍵的附加

兩個優點：

許多框架要求使用的整數主鍵字段。
如果您將記錄綁定到任何類型的用戶界面控件（例如，網頁上的輸入），與識別目的相比，將單個值附加到控件上比編碼和解碼更容易多列。

來源

2011-10-24 00:17:18

爲什麼在使用自動遞增PK和代理鍵作爲候選鍵時添加另一個表？儘管SQLite *總是*提供了一個ROWID又名「int PK」 - 但我仍然放棄了/沒有/單一的「PK」 - 但仍然發現信息仍然可以在適當的約束下在模型中編碼「減少」另一[候選/覆蓋]指數，就減少插入時的碎片而言可能「更便宜」。如果候選人索引對錶格進行了非規範化處理，那麼它從未成爲[代理人] PK的有效候選人，開始於... – 2011-10-24 00:22:04

物料清單與產品，子部件，組件。在子程序集中，（ProductID，AssemblyName）是唯一的。如果您將此用作組件中的PK和FK，則可以使用僅使用組件的產品查找組件使用情況。如果使用代理整數主鍵，則必須加入子組合（或使用子查詢技術）以獲取該信息。 –

謝謝你的簡潔的答案。代理人確實吸引更多，因爲我的大部分查詢可能不會基於密鑰（而是屬性，例如分數）。儘管數據庫和編輯的構建似乎更多，查詢可能需要更長時間。 – jobobo

代理鍵與複合鍵

回答

相關問題