C# 数据库设置（多个表使用1个地址表）

我有一个地址表，其中id作为主键。我知道这不是最好的方法，但它与问题无关

我还有另外3张表：供应商、个人和客户。它们都有一个id作为PK

我想在其他3个表中使用这1个地址表。通过在my 3 other tables中将Address.id用作不可为空的FK，很简单业务规则规定供应商、个人或客户必须始终具有地址，因此不允许为空值

我可以很容易地让它工作

但有人告诉我另一种方法：

完全删除供应商、个人和客户的FK，并创建一个名为ADDRESS_REL的新表，其中包含以下列：

地址\不允许为空 允许供应商id为空 允许人员id为空 允许客户端id为空 第二种方法有一些优点和缺点

缺点：

当我有30个地址相同的人时，我的地址表中有1行，个人表中有30行，地址表中有30行。另外，我的地址表中的这30行也有 某些空列供应商id和客户id

当我引入另一个数据库表时，比如说COMPANY，我希望它有一个ADDRESS to，我必须extand ADDRESS_REL表，列COMPANY_id也引入一个额外的空列

我必须使用数据库存储过程来确保供应商、个人和客户始终有一个地址我不能在我的程序代码中这样做，因为有时我们在数据库中硬编码数据，我想确保供应商、个人和客户的业务要求始终有一个地址

优点：

没有一个

---

实际上我想不出一个好的理由，但我想在开始实现和可能构建新的数据库结构之前好好考虑一下。我的问题是和我一起思考，也许我忽略了什么。我现在倾向于使用第一种方法，除非人们能用一些新的论点说服我……

你的问题是什么？如果关于第一种方法的问题比我能说的少，第一种方法是正确的，而且性能和空间消耗也很明智…坦白说：有人提出了一个垃圾解决方案-不要这样做！使用您最初使用的FK方法-这更有意义！我更喜欢这种垃圾解决方案，因为它适合某些情况。比如，我有一些常量表，行不太可能被更改，而事务表有很多CRUD。例如，配置表；所以我只是在其他几个常量值承载表之间创建一个关系表，并通过该配置表自定义应用程序的组合。。。我100%同意marc_在你的场景中的观点，我不认为有任何理由不使用FK。我建议不要为所有链接到某个地址的东西都使用一个链接表，为clientaddress使用一个链接表，为PersonalAddress使用另一个链接表等等。虽然根据我的经验，链接表会给L2E/EF带来麻烦，因为在查询时缺少导航属性和所需的连接。第一种方法是，谢谢大家的反馈！