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

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表而存在，因此未定義任何關(guān)系。由于任何一種產(chǎn)品都可以具有許多等級，因此PRODUCTS表與PRODUCT_RATINGS表具有一對多的關(guān)系。這很明顯。

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

我的問題：" CustID"列是否應(yīng)定義為與CUSTOMERS表建立一對多關(guān)系的外鍵？我看不到在哪里需要此數(shù)據(jù)的聯(lián)接。據(jù)我所知，" CustID"列僅在應(yīng)用程序中用于區(qū)分哪個客戶發(fā)布了評級...

請注意，在此模式下ProdRateIDPK是多余的-基于您在(prodid，cust)或(prodid，custid，timerated)上具有完全適當(dāng)?shù)腜K

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

我不熟悉您提到的這個問題："在架構(gòu)中"過度使用"外鍵關(guān)系"。 通常問題是使用不足。

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

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

我認(rèn)為通過我進(jìn)行循環(huán)的事情是當(dāng)他們開始談?wù)撫槍δ奶囟ㄐ枨筮M(jìn)行規(guī)范化和非規(guī)范化，并開始認(rèn)為如果沒有發(fā)生聯(lián)接，則無需在PRODUCT_RATINGs表中將CustID列作為外鍵進(jìn)行索引。 。 我了解您對保證CustID有效的含義。 如果刪除客戶，但仍然存在不相關(guān)的數(shù)據(jù)，可能會導(dǎo)致嚴(yán)重的問題。

是，product_ratings表中的CustId字段應(yīng)該是客戶表的外鍵。 這就是數(shù)據(jù)庫規(guī)范化的全部內(nèi)容。 我沒有讀過與您讀過的同一本書，但是我聽說過有關(guān)Mere Mortals的數(shù)據(jù)庫設(shè)計的好消息。

總結(jié)

以上是生活随笔為你收集整理的mysql主外键引用关系,关于mysql：数据主/外键关系的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。