数据库设计 - 跨 3 个表的外键和主键关系答案

【问题标题】：Database Design - Foreign Key and Primary Key relationships across 3 tables数据库设计 - 跨 3 个表的外键和主键关系
【发布时间】：2014-07-09 09:48:18
【问题描述】：

作为我自己的个人项目，我正在尝试将我们现有的一个 Access 数据库工具重新设计到 VB.net 中。这包括从头开始重新设计数据库，因为当前的数据库绝对是一团糟。

这是我目前在 SQL Server 中重新设计的数据库：

现在要明确关系：

在Client 表中，Client_ID 是主键。这与 Contracts.Client_ID 作为其外键有关系。这也与作为其外键的Sites.Client_ID 有关系。

在Sites 表中，Site_ID 是主键。这与 Contracts.Site_ID 作为其外键有关。

每个表中的每个主键在每次创建记录时都会自动递增 1。

这里的想法是一个简单的客户/站点/合同结构。例如，客户：Microsoft，站点：Reading Head Office，合同（可以适用于整个公司或单个站点的任何类型的合同）。

没有客户就没有网站。您应该能够将合同链接到客户或站点。目前我已经在合同中允许 Site_ID 和 Client_ID 的 Nulls 来促进这一点，因为我找不到任何方法来确保至少填写一个。

此设计是否合理并遵循最佳实践？我尝试按照网络上发现的许多不同建议遵循最佳实践，为不同类型的数据命名分隔表。任何意见将不胜感激

【问题讨论】：

如果站点有client id，而合约有site id，则合约不需要client id。

标签： sql sql-server database database-design primary-key

【解决方案1】：

我会做类似的事情

客户

ClientID PK，名称

只有特定于客户的属性

Client_Contracts

ClientID FK [Clients(ClientID)], ContractID FK (Contrats[ContractID])

合同

ContractID(PK)、StartDate、EndDate、SiteID FK（站点 [SiteID]）

仅合同必须具有的属性。

网站

SiteID PK，一个站点的所有列。

【讨论】：

将合约引用分离到自己的表有什么好处？那么它不会也跟着制作一个 Site_Contracts 吗？真的很感兴趣，请不要以为我说你错了，我只是想了解背后的原因:)
如果您在同一个站点上有两个客户端，您将最终重复站点表中的所有信息，以便为该站点添加另一个客户端。这违反了数据库规范化的规则。您的目标应该是减少 OLTP 应用程序数据库中的数据冗余。
我明白了，我没有考虑到这一点，因为一个站点上永远不会有两个客户。这背后的真实数据集可能每个客户只有一个站点，但对于少数人来说，他们在英国有 5 个站点，它们属于同一个客户；但是一个站点永远不会有两个客户。抱歉，如果我让您感到困惑！
我不了解您的业务需求，但如果您认为合同可以跨越多个站点，是的，那么您还应该有一个 Contract_Sites 表。并进一步规范您的数据库。

【解决方案2】：

我建议您查看creating and altering CHECK constraints。 (Client_ID IS NOT NULL OR Site_ID IS NOT NULL)的简单条件

附带说明，该结构应该适用于业务规则。客户可以在没有工作地点的情况下与之签订合同吗？这有意义吗？如果是这样，那就用你所拥有的，如果不是，我建议要求合同的站点信息（你将在哪里发送发票？），因此你可以从合同中删除 client_id。

鉴于这里的情况很简单，我不会深入探讨其他考虑因素，例如电话号码应该附加到网站还是联系人？我会说联系方式，因为续约人的电话号码可能与签订合同的人非常不同。

【讨论】：

感谢您的回复。我不知道检查约束，所以这非常有帮助。是的，客户可以在不将其链接到网站的情况下签订合同。用一个真实的例子来证明，我们是一个 MSP。假设我们与名为 Acme Ltd 的客户签订了合同，他们有 5 个站点，Acme London、Acme Paris 等。Acme Ltd 为其所有员工提供 Office 365。这种类型的合同应该链接到客户而不是网站，因为它包含所有网站。这让我意识到我可能需要在客户表中添加更多列。你帮了大忙:)