EER图中主键和外键的用法

Question

在我的数据库中，我有三个表（我有更多表，但如果大小写相等，用户可以是公司或一个人）。

• Users有一个主键id_user ；
• Company有一个主键id_company和一个外键users_id_user ;
• job_offers有一个主键id_job_offers和两个外键： company_id_company和company_users_id_user 。

我的问题是：

1. 主键在job_offers中job_offers吗？ 我不认为这是有原因的。
2. job_offers有两个外键，一个与company相关，另一个与users 。 这有问题吗？ 是否存在另一种完成同一任务的方式？

Answer 1

所有表都应具有主键。 听起来您好像在问您的主键应该是代理键还是自然键 。

您可能也会问其他表的相同问题。 例如，假设用户表中的email列是必需的并且是唯一的，则可以将其用作（自然）主键。

这个问题已经进行了激烈的辩论，并且两种方法都可以起作用（混合方法也可以）。 如果您想大致阅读此主题，请在Google上搜索“自然键与替代键”。

Answer 2

1. 我想你是正确的。 那里不需要单独的id字段。 这两个外键应共同构成表的主键。
2. 在我看来很好。

Answer 3

1）有意义在job_offers中的主键吗？ 我认为没有理由

是的，那里-每个表都应该有一个主键。 这就是所谓的“规范化”。

您的选择可能不是很好。 我想说两个外键应该一起是主键，而不是id列。

2）工作机会有两个外键，一个与公司有关，另一个与用户有关，有什么问题吗？ 是否存在另一种方式（最佳方式）来做到这一点？

不，这就是建立多对多关系的方式。

Answer 4

主键在job_offers中有意义吗？ 我不认为这是有原因的。

是的。 我同意每个表都应该有自己的PK。 每个表都应该有一个主键吗？

我还有更多，但前提是平等，用户可以是公司或单身人士

job_offers有两个外键，一个与公司相关，另一个与用户相关。 这有问题吗？ 是否存在另一种完成同一任务的方式？

该系统有两种类型的用户：普通用户（个人）和公司用户。 job_offers是一个表，用于保存公司的工作机会。 如果公司用户要发布工作，则记录将插入到job_offers表中。 然后，一旦普通用户获得此工作机会，就将job_offers.company_user_id_user分配给该普通用户的用户ID。

但是从您的ER图中， Company.users_id_user是PK，不能为null，并且此PK在job_offers.company_users_id_user用作FK。 因此job_offers.company_users_id_user也不能为null。

结果，它无法处理公司用户刚刚发布工作且普通用户没有获得该工作机会的情况， job_offers.company_users_id_user最终没有人获得该工作机会的情况。在这种情况下， job_offers.company_users_id_user应该设置为null，这违反了job_offers.company_users_id_user的非null约束。

我将使用此设计完成相同的任务：

Users
=================
id_user (PK)
email 
activation
password

Company
=================
id_company (PK)
activities 
foundation 
user_id (FK to Users)
description

job_offer
=================
id_job_offer (PK)
id_company (FK to Company)
description_offer 
tags

user_offer
=================
id (PK)
user_id (FK to Users)
job_offer_id (FK to job_offer)