一对多，多对多纠正表中的关系错误

Question

enter image description here我正在为草坪护理业务客户，工作，费用，付款创建数据库。我在设计此数据库时遇到问题，即PK-FK问题。很难将我的头围绕一对多，多对多。我非常确定我需要一个“客户和地址”表，其中的“地址”表与“客户表”中的外键链接在一起，以便一个客户可以有多个地址等。

我使用了来自多个网站的有关关系数据库管理的示例。

客户表（客户有多个地址，这让我不满意！我需要为此应用程序使用单独的地址表吗？） PK-客户ID（客户可以有多个地址，付款，工作，费用）      客户名称      地址      电话 ＃      电子邮件

付款表 PK付款ID      客户编号，      工作编号      费用编号，      支付日期      支付金额      评论

费用表 PK费用ID      客户编号，      工作编号      付款编号，      费用金额，      费用说明，

工作表 PK职位ID      客户编号，      费用编号，      付款编号，      日期（工作完成），      开始时间，      时间结束，      割完了（是/否Booleen），      修剪$金额（十进制），      每小时工作（是/否）      工作时间，      每小时$金额，      说明，

我希望当我为一个客户端输入多个地址时，我将为为其添加的每个新地址获得一个新的客户端ID。对于付款，工作等也是如此。我希望每个客户都有一个唯一ID，该ID可以链接到多个地址，工作，付款ETC。我觉得我已经接近了……只是希望有训练有素的眼睛看看！非常感谢！

Answer 1

除了这些评论外，我还会：

## Clients
ClientID
ParentClientID references Clients.ClientID
BillingAddressID references Addresses.AddressID
ContactAddressID references Addresses.AddressID

## Sites
SiteID
ClientID references Clients.ClientID
SiteAddressID references Addresses.AddressID
SiteManagerAddressID references Addresses.AddressId

## Addresses
AddressID

## Chargeables
SiteID references Sites.SiteID

## Payments
ClientID references Clients.ClientID

由于割草是重复性的事情，因此站点表条目将记录割草的站点，割草的开始和结束月份以及任何年份和频率。收费表的作用类似于该站点上发生的所有收费事件的历史记录，包括每次被修剪的情况（因此，如果您跳过一周，则不对其进行收费，也不编写收费表），还可以进行杂草清理等额外服务，沟清洁，排水沟挖掘，绿篱切割等作为一个整体。如果定期进行树篱修剪，我可能会建议最终用户在（可以使用相同的addressid）另一个地方放置树篱修剪，尤其是在修剪周期不同的情况下。因此，如果站点表的工作更多地是关于站点上发生的工作，而不是站点本身，则最好调用站点表Job。 如果割草不完整，则可以进行多次收费记录，反映出修剪的日期，记录割草未完成可能并不重要，但如果是这样，也许没有日期或将来日期的收费记录可以作为“预定任务” “？某人帐户的状态可以通过将所有应付款和所有付款相加得出

您可能会花很多钱，但是这里的核心建议是：

• 有一个地址表
• 还有许多其他表具有XAddressID列，其中X是地址的目的
• 您甚至可以为每个客户端/站点/任何地方拥有多个地址，但是将它们全部定义为目的。只需获取每个实体需要跟踪的所有类型的地址的列表，并为其创建XAddressID
• 网站由客户拥有，并且有修剪的地址，客户有发送账单的地址
• 客户可能存在于一个层次结构中，并且计费可能发生在不同的层次结构级别以进行站点工作，使客户表自引用，并且billingaddress为null或不允许您跟踪特定客户的计费位置。业务规则“如果帐单地址为空，则向上层次结构直到遇到非空值”可以允许叶层次结构级别拥有自己的帐单地址，即使更靠近根节点的节点没有一个并向父级计费

再说一下我所说的地址自由转换的复杂性，您确实可以拥有一个Client，Address和ClientAddress（3列，addresstype，clientid和addressid）表，并允许该客户机完全具有任何类型的地址，只需将“帐单”，“紧急联系”，“书信”，“董事总经理的住所”，“首席执行官的母亲”或类型栏中的任何内容。.但是，有两点需要考虑：

人们不想要那么多选择；这对他们来说是头疼，对您来说也是头疼：
• 如果您对某些类型的地址（紧急联系人，帐单）有某种程序上的依赖，则必须编写业务规则，以检查每个客户是否都记录了这两种地址类型，特别是如果该字段完全自由形式。

由于您必须提供多个地址等的选择列表，因此UI变得更加复杂

“寻求简单的解决方案，而不是完美的解决方案”