我想對于那些已經開發了許多數據庫模式的人來說，這將是一個簡單的答案，但是我最近發現自己承擔了優化(或嘗試優化)數據庫模式的任務，并且一直在閱讀"高性能MySQL"，并且剩下一個關于在模式中使用或"過度使用"外鍵關系的問題。例如，假設我有以下表格：

CUSTOMERS:

__________________________________

|CustIDPK| ?Name ?| ? RegDate ? ?|

----------------------------------

| ? 1 ? ?| ?frank | ?01-30-2014 ?|

| ? 2 ? ?| ?terry | ?02-01-2014 ?|

| ? 3 ? ?| ?amber | ?02-02-2014 ?|

| ? 4 ? ?| ?sara ?| ?02-06-2014 ?|

PRODUCTS:

____________________________________

| ProdIDPK | ProdName | AddedDate ?|

------------------------------------

| ? ?1 ? ? ?| ?Phone ?| 01-01-2014 |

| ? ?2 ? ? ?| ? TV ? ?| 01-02-2014 |

| ? ?3 ? ? ?| Tablet ?| 01-02-2014 |

| ? ?4 ? ? ?| ? PC ? ?| 01-05-2014 |

PRODUCT_RATINGS:

__________________________________________________________________

| ProdRateIDPK | ?ProdIDFK | ?CustID | ?Rating | ? ?TimeRated ? ?|

------------------------------------------------------------------

| ? ? 1 ? ? ? ?| ? ? 1 ? ? | ? ?1 ? ?| ? 8 ? ? | ? 01-01-2014 ? ?|

| ? ? 2 ? ? ? ?| ? ? 1 ? ? | ? ?2 ? ?| ? 7 ? ? | ? 01-01-2014 ? ?|

| ? ? 3 ? ? ? ?| ? ? 1 ? ? | ? ?3 ? ?| ? 8 ? ? | ? 01-02-2014 ? ?|

| ? ? 4 ? ? ? ?| ? ? 2 ? ? | ? ?4 ? ?| ? 6 ? ? | ? 01-02-2014 ? ?|

| ? ? 5 ? ? ? ?| ? ? 2 ? ? | ? ?4 ? ?| ? 6 ? ? | ? 01-03-2014 ? ?|

| ? ? 6 ? ? ? ?| ? ? 2 ? ? | ? ?3 ? ?| ? 4 ? ? | ? 01-01-2014 ? ?|

| ? ? 7 ? ? ? ?| ? ? 3 ? ? | ? ?2 ? ?| ? 5 ? ? | ? 01-02-2014 ? ?|

| ? ? 8 ? ? ? ?| ? ? 3 ? ? | ? ?1 ? ?| ? 7 ? ? | ? 01-03-2014 ? ?|

| ? ? 9 ? ? ? ?| ? ? 3 ? ? | ? ?1 ? ?| ? 4 ? ? | ? 01-04-2014 ? ?|

| ? ? 10 ? ? ? | ? ? 4 ? ? | ? ?2 ? ?| ? 9 ? ? | ? 01-04-2014 ? ?|

| ? ? 11 ? ? ? | ? ? 4 ? ? | ? ?3 ? ?| ? 8 ? ? | ? 01-01-2014 ? ?|

| ? ? 12 ? ? ? | ? ? 4 ? ? | ? ?4 ? ?| ? 7 ? ? | ? 01-01-2014 ? ?|

CUSTOMERS表獨立于PRODUCTS表而存在，因此未定義任何關系。由于任何一種產品都可以具有許多等級，因此PRODUCTS表與PRODUCT_RATINGS表具有一對多的關系。這很明顯。

現在，在PRODUCT_RATINGS表中的現有架構中，CustID列是CUSTOMERS表的外鍵，代表與產品評分的一對多關系，因為任何用戶都可以在該表中擁有許多評分(每個評分代表一個單獨的產品)。

我的問題：" CustID"列是否應定義為與CUSTOMERS表建立一對多關系的外鍵？我看不到在哪里需要此數據的聯接。據我所知，" CustID"列僅在應用程序中用于區分哪個客戶發布了評級...

請注意，在此模式下ProdRateIDPK是多余的-基于您在(prodid，cust)或(prodid，custid，timerated)上具有完全適當的PK

任何兩個表都可以連接。 它們之間存在FK只是意味著該聯接將為每個引用的表行包含一個結果行。 只需向它們聲明所有候選鍵(即最小的PK / UNIQUE列集，即不包含較小者的列集)和FK。 (SQL要求您聲明在FK中引用的PK / UNIQUE列集。因此，您還必須聲明那些非最小的PK / UNIQUE列集和與之對應的FK，因此它們實際上是外來超鍵。)

我不熟悉您提到的這個問題："在架構中"過度使用"外鍵關系"。 通常問題是使用不足。

定義外鍵關系有幾件事情。 最重要的是，它保證PRODUCT_RATING s表中的CustId列在CUSTOMERS表中是有效的CustId。 那很有用。

這樣做有后果，但是要弄清楚這種關系的存在是好的模式設計的一部分。 不能通過不尋常的"優化"概念來消除它。

我認為通過我進行循環的事情是當他們開始談論針對您的特定需求進行規范化和非規范化，并開始認為如果沒有發生聯接，則無需在PRODUCT_RATINGs表中將CustID列作為外鍵進行索引。 。 我了解您對保證CustID有效的含義。 如果刪除客戶，但仍然存在不相關的數據，可能會導致嚴重的問題。

是，product_ratings表中的CustId字段應該是客戶表的外鍵。 這就是數據庫規范化的全部內容。 我沒有讀過與您讀過的同一本書，但是我聽說過有關Mere Mortals的數據庫設計的好消息。