將外鍵與非主鍵綁定有什么缺點嗎？

Question

假設我們有一個像這樣的工作表：

• 工作（編號，號碼）；

假設我們有一個客戶請求來跟蹤工作時間，我們創建一個表，如下所示：

• （A）job_timer（id，job_id，時間戳）；

但是我們可以選擇將其綁定到job表的方式，因此我們還可以：

• （B）job_timer（id，job_number，時間戳）；

假設job_number是UNIQUE 。

我有條件根據id來創建外鍵，因此A） job_id將是我所看到的方式。 但是，客戶正在按職位編號查找職位，如果我直接通過B） job_number查找，它將為我和數據庫節省一些工作。 但是我應該這樣做嗎？

我的意思是使用job_id時需要進行更多工作，即給定工作編號，我只需要使用job_timer表。 當給定job_id我需要同時綁定兩個表-更多的認知編程工作，更多的數據庫工作。

請注意，類似的問題非主鍵的外鍵解決了非主鍵的唯一性問題，但我認為它不能解決我的問題。

原始表（ job ）是遺留代碼庫的一部分，在該遺留代碼庫中，字段id和number都在整個代碼中得到了廣泛利用，在這種情況下，我有一個“拆分主鍵”條件。 由於缺乏完整的測試覆蓋范圍，因此將其清除是令人望而卻步的。 為什么要創建number字段以及為什么要使其成為varchar是個好問題。 我敢肯定在某個時候一定有原因。

我正在尋找“是的，繼續進行，這完全沒有問題，在這種情況下沒有最佳實踐 ”或“否，如果您這樣做，將來可能會遇到X，Y，Z問題”。

Answer 1

TL; DR當列列表的值必須作為另一個PRIMARY KEY或UNIQUE NOT NULL列列表的值出現時，請始終聲明 FOREIGN KEY約束（鏈）。 但是，當存在多個CK時，選擇將哪個CK（候選密鑰）作為FK（外鍵）引用最終是實用的。 該標准實質上是選擇PK（主鍵）的標准，因為將CK區分為PK最終是FK的首選。 典型的清單是熟悉性，不可還原性，穩定性和簡單性 。 在此，過去的使用表明任一CK都是合理的。 盡管考慮number僅用於最終輸出，但盡管id的存在和唯一性，也說明了它的varcharness和唯一性。 如果您同時包括兩者，那么請注意在該對上聲明FOREIGN KEY可能是合適的。 （要求在job的對上添加UNIQUE NOT NULL 。）

---

超鍵是一組唯一且不為null的列。 CK是一個超級鍵，其中不包含更小的超級鍵。 一個表可以有任意多個CK。 PK是傑出的CK。

我們可以說，當表中子行的值也是被引用表中某些超級鍵子行的值時，“外來超級鍵”成立。 如果超級鍵是CK，則外來超級鍵是FK。 我們告訴DBMS CK和外來超鍵，以便它可以防止無效的數據庫狀態。

SQL UNIQUE NOT NULL實際上聲明了一個超鍵。 因此，SQL PRIMARY KEY實際上聲明了一個專有的超鍵。 如果超級鍵為CK，則為PK。 SQL FOREIGN KEY實際上聲明了一個外來超鍵。 如果引用的超級鍵為CK，則為FK。

您的帶有“拆分PK”的表只是具有兩個CK的表。 （這形成一個超鍵，因為CK的所有超集都是超鍵。）就約束聲明而言，首要性是無關緊要的。 您應該只聲​​明保持的約束，以便DBMS可以實施它們。

請注意，如果您有一個id 和 number為FK的表，則很有可能必須在job出現一對值。 如果是這樣，則通過FOREIGN KEY將該對聲明為外鍵。 當存在自然鍵時，需要添加外鍵是一個具有替代鍵的缺點。 另一方面，只要有多個CK，就會出現這種情況。

PS唯一列集的任何超集都是唯一的。 但是，SQL要求您將FK的目標聲明為UNIQUE NOT NULL即使它必須已經通過包含一些較小的聲明為Unique的集合而已經是唯一的。 所以，當有一個id - number對，其中一對具有出現在job ，你應該申報的復合FK和復合超密鑰。 PPS所有這些聲明的重點是完整性，而不是為了優化而建立索引 。 （盡管這也很重要。）