我有一个关于在架构中使用相同FK的问题。这是问题
|=======================================|
| Book |
|=======================================|
| Book_ID (PK)| Cover_Paper | Page_Paper|
|-------------|-------------|-----------|
|====================================|
| Paper |
|====================================|
| Paper_ID (PK)| Paper_Type | weight |
|--------------|------------|--------|
假设我有不同类型的纸张，不同重量用于打印封面和页面。
所以我需要将Paper_ID作为FK插入Book表。问题是，将不同的列名称作为FK是错误的。如果我将表更改为相同的列名，那将是如此奇怪。
|==========================================|
| Book |
|==========================================|
| Book_ID (PK)| Paper_ID(FK) | Paper_ID(FK)|
|-------------|--------------|-------------|
有关此问题的任何帮助??
答案 0 :(得分：0)
列名与列的域名不同并没有错。事实上，这通常是必要的。
备选方案 - 具有两个具有相同名称的列 - 很糟糕。你怎么知道哪个栏目表明封面纸和哪个页纸？按位置？这将内容的含义与数据的物理表示联系起来。如果我选择Book_ID而只选择其中一个Paper_ID列会怎样？没有额外的外部信息，人们不会知道数据意味着什么。相反，附加信息应该是表示的一部分，因此它尽可能是自我描述的。
在每个角色由唯一域填充的关系中，只需使用域名作为角色名称就可以轻松实现，而不会产生混淆。如果一本书由单一类型的纸张组成，那么谈论该书的论文是有道理的。 一个自行车座椅和一个人的鼻子相同。
然而，当一个关系有多个同类事物时，我们需要指出每个事物的角色。像你一样区分Cover_Paper和Page_Paper是正确的方法。 （这太糟糕了，SQL DBMS没有为每列提供单独的角色和域名，但我离题了。）
你可以称之为Cover_Paper_ID和Page_Paper_ID，这是将ID附加到代理标识符列的行业约定，尽管我认为没有它会更好。在其他关系中，只编写没有域的角色通常就足够了 - 例如在Marriage中，我们可能会为Husband和Wife添加列，而不是撰写Husband_Person和Wife_Person。
Edgar Codd（大型共享数据银行数据关系模型的作者）和Peter Chen（实体 - 关系模型的作者 - 迈向统一的数据视图）在他们的论文中讨论角色。我强烈建议你们两个都学习，特别是因为很少有在线资源提到这个主题。