将佣金分成存储在数据库中并确保数据库完整性答案

【问题标题】：Storing commission splits in DB and insuring database integrity将佣金分成存储在数据库中并确保数据库完整性
【发布时间】：2010-01-22 02:11:35
【问题描述】：

这是背景：

销售代理销售保险。他们单独工作或在 2 人或更多人的机构中工作。当多个代理一起工作时，他们需要分摊佣金。佣金分配按百分比预定义。

例子

Joe、John 和 Saul 属于一个机构。

每卖出一份保单，Joe 将获得 40% 的佣金，John 获得 35%，Saul 获得 25%。

每个代理要么单独工作，要么是一个（也是唯一一个）代理的成员。

在数据库中对此建模的明显方法是 3 个表：一个 Agents 表、一个 Agency 表和一个 AgencyCommissionSplits 表。

代理表：

AgentID int PK
AgentName vchar(30),
AgencyID int FK Nullable

代理机构表：

AgencyID int PK,
AgencyName vchar(30)

CommissionSplits 表：

AgencyID int FK,
AgentID int FK,
Percentage dec(3,1)
(compound PK AgencyID, AgentID)

我看到的问题是我不知道如何确保任何给定机构的总百分比总和为 100%。我可以尝试在前端强制执行此操作，但我更希望在数据库中使用一种方式来强制执行此约束。

【问题讨论】：

【解决方案1】：

这是关于数据库约束的经典鸡或蛋场景。虽然立即选项看起来像编写检查约束，但这不切实际，因为数据必须在表中，然后约束才能验证它。如果您要创建一个新机构，那么您将插入新行，使您的表格（暂时）处于百分比相加不等于 100% 的状态。

最好的办法是在应用程序级别执行此操作；任何数据库解决方案（如果存在的话）都可能是相当数量的骇客（尽管我很高兴在这方面被证明是错误的）。

【讨论】：

【解决方案2】：

您是否熟悉检查约束（在 SQL Server 中）？它们非常灵活，可用于强制执行您在此处描述的情况。

【讨论】：

你并不完全正确。如何将数据插入 CommisionsSplits 表中。假设您要插入两行，每行占 50%。当您插入第一行时，检查约束将失败（因为它试图将机构内所有行的总和约束为 100）。我不会尝试在数据库中检查它，而是在域（业务）逻辑层中检查它。
我认为对您来说最好的检查约束是确保给定代理的佣金分配在 0 到 100 之间

【解决方案3】：

在我看来，该模型过于简单，但这取决于机构/设置的复杂性。

“特工 Joe”可以离开该机构并开始在另一个机构工作，但他之前的机构的持续佣金仍必须与他相关联。在给定的时间点，他是 1 家且只有 1 家机构的成员（遵守您的规则），但数据库可能需要在历史上保持准确才能处理随时间支付的佣金。

当他们将“Joe”替换为“Bill”时，除非考虑到日期，否则反对该机构的所有代理的百分比将再次超过 100%。

我也不排除随着代理机构的扩大，他们被允许更多的组合，因此 10 名销售人员不会自动获得每项政策的百分比，但他们会指出谁销售了产品以及各自的佣金是多少是。

根据您的具体设计，Agent.AgencyID 可以为 nullabe，但佣金拆分需要 Agent 和 AgencyID，所以除非您考虑缺少佣金拆分记录 = 100%，否则它会给您带来问题。

【讨论】：

【解决方案4】：

如果您需要将它放在数据库中，这是最好在触发器中完成的事情。但这会很复杂。

但是。您的部分问题是，在数据库中输入的第一个人（在您输入其他两个将进行拆分之前）不会加起来为 100，除非第一个人被定为 100。那么您如何确定更新加起来超过100或者不到100怎么办？如果数字加起来不等于 100%，你会从谁那里削减百分比或将百分比添加给谁？

最好只将记录标记为未添加到 100% 并拒绝 apy 佣金，直到手动解决问题。

【讨论】：

【解决方案5】：

“我可以尝试在前端强制执行此约束，但我更希望在数据库中使用一种方式来强制执行此约束。”

现有的唯一可以为您执行此操作的 DBMS 是我自己的：http://shark.armchair.mb.ca/~erwin

约束聚合（并以尽可能高的效率/性能水平进行）是（我说得委婉一点）约束执行中更棘手的问题之一，世界上没有一个人除了我谁知道怎么做。

你可以相信我，你可以发现我傲慢与否，但我要告诉你的是，你不会从任何主要的 DBMS 获得“在数据库中强制执行此约束的方法”在未来最初的几十年中的任何一个供应商。他们一点头绪都没有，甚至他们并不真正关心这个问题。

如果您对来自专业的垃圾 DBMS 感到困惑，请阅读其他解决方案并实施类似“只需将记录标记为未添加到 100% 并拒绝 apy 佣金，直到手动解决问题。”。

【讨论】：