将不同帐户类型(数据库类型)关联到付款和发票的正确方法是什么?
What's the proper way to associate different account types (database types) to payments and invoices?
在我开发 Web 应用程序的过程中,我 运行 遇到了一些困难。为了简单起见,我已经将应用程序的复杂性归结为这个问题。
此 Web 应用程序的目的是销售保险。保险可以通过代理人 (Agency) 或直接通过 phone 购买 (Customer)。保单可以通过代理机构支付,也可以由客户直接支付。因此,从多个来源 (Agencies/Customers) 欠款(开具发票)和收到(付款)。
结算选项:
- 代理商(代理商在应用程序外从客户处收集)
- 客户
这就是事情变得复杂的地方。代理商存储在与客户不同的数据库 table 中(原因很明显)。但是,代理商和客户都需要能够付款并获得分配给他们的发票。我很难弄清楚如何创建适当的数据库模式以允许将两种类型的数据库记录连接到它们的发票和付款。
我最初的计划是建立单独的关系(加入)table,即 link 代理和客户 invoices/payments。
但是,既然我一直在思考这个问题,我认为将代理机构和客户合并为一个 "Payee" table 可能会有所帮助,然后与payments/invoices。收款人 table 只会存储一个主键。它不会包含收款人的真实姓名或信息 - 相反,我会通过与代理机构或客户的 JOIN tables.
提取该数据
无论我选择哪种解决方案,我在创建新付款记录时仍然面临的问题是我需要扫描代理商和客户table 以寻找可能的收款人。我想知道从数据库模式的角度(或从 accounting/e-commerce 的角度)是否有合适的方法来解决这个问题。
处理这种情况的正确方法是什么?欢迎所有想法和可能的解决方案!
更新 01:
经过一些有用的建议(见下文)后,我想出了一个可能的解决方案,可以在保持数据规范化的同时解决这个问题。
这种方法让我感到困惑的一件事是,我将不得不进行多次 table 选择以获得所有可能付款的人的列表 and/or分配给他们的发票。
虽然在这种情况下这可能是不可避免的,因为确实有不同的 "types" 人可以与付款和发票相关联。我遇到了一种情况,我有两种不同类型的记录需要与同一事物相关联。在上面的方法中,我使用 FKs link 每个 table (Agencies/Customers) 到收款人记录(统一 Agencies/Customers 的 table 和然后最终 link 将它们发送到付款和发票。
这是正确的解决方案吗?还是我忽略了什么?
我的建议是:而不是收款人 table - 有两个链接 table:
PayeeInvoices {
Id, --PK
PayeeId,
PayeeType,
InvoiceId --FK to Invoices tabse
}
和
PayeePayments {
Id, --PK
PayeeId,
PayeeType,
PaymentId --FK to Payments table.
}.
PayeeType
是两个选项:客户或代理商。新建支付记录时可以通过InvoiceId
查询PayeeInvoices
得到PayeeType
和对应的PayeeId
,然后在对应的table中查找其余数据s.
编辑:
现在正在考虑。除了两个额外的 table PayeeInvoices
和 PayeePayments
,您可以只在 Invocies
和 [=22= 中添加 PayeeId
和 PayeeType
列] tables,假设发票或付款仅属于一个收款人(客户或代理商)。不过,我的两个解决方案都没有真正规范化。
有几个选项:
您可以像对待 OOP 编程和继承那样来表达。
- 有一个 table
Person
包含一个唯一 ID 和一个类型(代理、客户,未来更多)。此外,您可以添加带有元数据的列,例如 who inserted/when/why 和 status/soft-delete/??? 的列
- 有两个 table 代理和客户,都持有
PersonID
作为 FK。
- 你的
Payee
就是那个人
您可以在一个结果中使用模型绑定 VIEW
和 UNION ALL
到 return 两个 table 模型。此视图上的唯一索引应确保您将拥有一个唯一键,至少作为 table-source 和那里的 ID 的组合。
你可以使用中间 table 和 table-source 和 ID there 作为唯一的 Key 并使用这两个-您付款过程中的列 ID
肯定还有几个...
我最好的朋友是第一个选择...
在我开发 Web 应用程序的过程中,我 运行 遇到了一些困难。为了简单起见,我已经将应用程序的复杂性归结为这个问题。
此 Web 应用程序的目的是销售保险。保险可以通过代理人 (Agency) 或直接通过 phone 购买 (Customer)。保单可以通过代理机构支付,也可以由客户直接支付。因此,从多个来源 (Agencies/Customers) 欠款(开具发票)和收到(付款)。
结算选项:
- 代理商(代理商在应用程序外从客户处收集)
- 客户
这就是事情变得复杂的地方。代理商存储在与客户不同的数据库 table 中(原因很明显)。但是,代理商和客户都需要能够付款并获得分配给他们的发票。我很难弄清楚如何创建适当的数据库模式以允许将两种类型的数据库记录连接到它们的发票和付款。
我最初的计划是建立单独的关系(加入)table,即 link 代理和客户 invoices/payments。
但是,既然我一直在思考这个问题,我认为将代理机构和客户合并为一个 "Payee" table 可能会有所帮助,然后与payments/invoices。收款人 table 只会存储一个主键。它不会包含收款人的真实姓名或信息 - 相反,我会通过与代理机构或客户的 JOIN tables.
提取该数据无论我选择哪种解决方案,我在创建新付款记录时仍然面临的问题是我需要扫描代理商和客户table 以寻找可能的收款人。我想知道从数据库模式的角度(或从 accounting/e-commerce 的角度)是否有合适的方法来解决这个问题。
处理这种情况的正确方法是什么?欢迎所有想法和可能的解决方案!
更新 01:
经过一些有用的建议(见下文)后,我想出了一个可能的解决方案,可以在保持数据规范化的同时解决这个问题。
这种方法让我感到困惑的一件事是,我将不得不进行多次 table 选择以获得所有可能付款的人的列表 and/or分配给他们的发票。
虽然在这种情况下这可能是不可避免的,因为确实有不同的 "types" 人可以与付款和发票相关联。我遇到了一种情况,我有两种不同类型的记录需要与同一事物相关联。在上面的方法中,我使用 FKs link 每个 table (Agencies/Customers) 到收款人记录(统一 Agencies/Customers 的 table 和然后最终 link 将它们发送到付款和发票。
这是正确的解决方案吗?还是我忽略了什么?
我的建议是:而不是收款人 table - 有两个链接 table:
PayeeInvoices {
Id, --PK
PayeeId,
PayeeType,
InvoiceId --FK to Invoices tabse
}
和
PayeePayments {
Id, --PK
PayeeId,
PayeeType,
PaymentId --FK to Payments table.
}.
PayeeType
是两个选项:客户或代理商。新建支付记录时可以通过InvoiceId
查询PayeeInvoices
得到PayeeType
和对应的PayeeId
,然后在对应的table中查找其余数据s.
编辑:
现在正在考虑。除了两个额外的 table PayeeInvoices
和 PayeePayments
,您可以只在 Invocies
和 [=22= 中添加 PayeeId
和 PayeeType
列] tables,假设发票或付款仅属于一个收款人(客户或代理商)。不过,我的两个解决方案都没有真正规范化。
有几个选项:
您可以像对待 OOP 编程和继承那样来表达。
- 有一个 table
Person
包含一个唯一 ID 和一个类型(代理、客户,未来更多)。此外,您可以添加带有元数据的列,例如 who inserted/when/why 和 status/soft-delete/??? 的列
- 有两个 table 代理和客户,都持有
PersonID
作为 FK。 - 你的
Payee
就是那个人
- 有一个 table
您可以在一个结果中使用模型绑定
VIEW
和UNION ALL
到 return 两个 table 模型。此视图上的唯一索引应确保您将拥有一个唯一键,至少作为 table-source 和那里的 ID 的组合。你可以使用中间 table 和 table-source 和 ID there 作为唯一的 Key 并使用这两个-您付款过程中的列 ID
肯定还有几个...
我最好的朋友是第一个选择...