在這種情況下，代理鍵是否比自然鍵好

我從這裡複製了這段程式碼：

CREATE TABLE records(
   email TEXT REFERENCES users(email),
   lat DECIMAL,
   lon DECIMAL,
   depth TEXT,
   upload_date TIMESTAMP,
   comment TEXT,
   PRIMARY KEY (upload_date,email)
);

CREATE TABLE samples(
   date_taken TIMESTAMP,
   temp DECIMAL,
   intensity DECIMAL,
   upload_date TIMESTAMP,
   email TEXT,
   PRIMARY KEY(date_taken,upload_date,email),
   FOREIGN KEY (upload_date,email) REFERENCES records(upload_date,email)
);

引起我注意的第一件事是使用自然複合鍵作為兩個表的主鍵。

我能夠從這段程式碼中提取 3 件事：

1. 該users表（此處未顯示）email用作類型的主鍵text..
2. 該records表使用text+的複合鍵timestamp。
3. 該samples表使用 3 個 ++ 類型欄位的複合text鍵。timestamp``timestamp

現在在這種情況下，代理鍵不是更好的辨識嗎？我的意思是在性能方面索引 aint應該比索引 a 更好text？有什麼東西可以使代理鍵成為一個糟糕的選擇嗎？

對於任何 PK，無論是複合的還是單一的，電子郵件都是一個特別糟糕的選擇。請參閱我在 Stack Overflow 上對這個問題的回答，了解原因：

https://stackoverflow.com/questions/3804108/is-email-address-a-bad-primary-key/3804174#3804174

我會考慮兩個因素：

• 主鍵值不應更改或重用。電子郵件地址往往會發生變化。我通常對數據庫中的使用者 ID 使用代理項。
• 當長字元串不是索引中的第一個欄位時，它們往往會破壞索引鍵壓縮。根據數據的聚合方式，可以通過將電子郵件地址移動到索引中的第一個欄位來解決此問題。

使用更好地代表電子郵件地址所代表的概念的代理鍵可能是更好的解決方案。也許像contributor_id 這樣的欄位可能是一個更好的欄位。可能需要將電子郵件地址轉換為該欄位的附加表格。

編輯：我再次查看了您的設計。您可能希望查看建模採樣事件（位置和所用時間）、樣本和電子郵件地址。樣本將是採樣事件的孩子。採樣事件表上的代理鍵可能適用於採樣事件表，以在將鍵遷移到子表時限制鍵中的列數。

我不知道你在採樣什麼以及它是如何聚合的。在設計中應考慮如何聚合數據。

引用自：https://dba.stackexchange.com/questions/31511