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 中有意义吗？我认为这是没有理由的。
2. job_offers 有两个外键，一个与company 相关，另一个与users 相关。这有问题吗？是否存在另一种方法来完成相同的任务？

Answer 1

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

您可能也会向其他桌子问同样的问题。例如，假设 users 表中的 email 列是必需的且唯一的，则它可以用作（自然）主键。

这个问题引起了激烈的争论，两种方法都可以工作（混合方法也可以）。如果您想总体了解这个主题，请在谷歌上搜索“自然与代理键”。

Answer 2

主键是否有意义
工作机会？我不认为那里
这是一个原因。

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

我还有更多，但情况相同，
用户可以是公司或个人
人

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

系统有两种类型的用户：
普通用户（个人）和公司用户。
job_offers是一个表，保存
公司提供的工作机会。如果一个
公司用户想要发布职位、
记录将被插入到
job_offers 表。然后一旦
普通用户得到这份工作offer后，
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 应该设置为 null ，这违反了 job_offers.company_users_id_user 的非空约束。

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

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)

Answer 3

1) 使主键有意义
工作机会？我觉得没有什么理由

是的 - 每个表都应该有一个主键。这就是所谓的“标准化”。

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

2) 工作机会有两个外国人
密钥，一个与公司相关，另一个与其他相关
对用户来说，有什么问题吗？存在另一个
方法（最好的方法）来做到这一点？

不，这就是多对多关系的完成方式。

Answer 4

1. 我认为你是对的。那里不需要单独的 id 字段。这两个外键应该一起构成表的主键。
2. 对我来说看起来不错。