我想对于那些已经开发了许多数据库模式的人来说，这将是一个简单的答案，但是我最近发现自己承担了优化(或尝试优化)数据库模式的任务，并且一直在阅读"高性能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的数据库设计的好消息。