我认为对于已经开发了许多数据库模式的人来说，这将是一个简单的答案，但我最近发现自己的任务是优化（或尝试优化）数据库模式，并且已经阅读了“高性能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'列仅用于应用程序，以区分哪个客户发布了评级......
答案 0 :(得分：1)
我不熟悉你提到的这个问题：''过度使用'模式中的外键关系'。通常问题是使用不足。
定义外键关系可以做几件事。最重要的是，它保证CustId表中的PRODUCT_RATING列在CustId表中是有效的CUSTOMERS。这非常有用。
这会产生一些后果，但澄清这种关系存在是良好架构设计的一部分。这不是一个被“优化”的不寻常概念所消除的东西。
答案 1 :(得分：0)
是的，product_ratings表中的CustId字段应该是customers表的外键。这就是数据库规范化的全部内容。我没有读过你所做过的同一本书，但我听说过关于数据库设计的好东西。