发票和交易的模式设计——“神秘”关系答案

【问题标题】：Schema Design for Invoices and Transaction - "mystery" relation发票和交易的模式设计——“神秘”关系
【发布时间】：2014-11-24 10:37:12
【问题描述】：

我对我在项目中遇到的问题有疑问。问题是关于 DB 的模型，更准确地说：我如何对这种关系建模（起初我认为这将是简单的 M:M，但经过一些思考后它并不那么明显；））。我有一些想法，但也许有人会有更好的东西:)

我的问题是关于以下问题：

我有 2 张桌子。一个有例如发票，第二个 - 交易。一张发票可以匹配多笔交易，一笔交易可以匹配多张发票。我想允许用户进行一些匹配，以便他可以选择发票（一个或多个），选择交易（一个或多个）并单击“匹配”。但是点击“匹配”后，所有使用过的记录（发票和交易）都不能再使用了。我的想法是：

使用标准关联表，但有 3 列：idIncoive、IdTransaction 和用于匹配信息的唯一 id。并将唯一约束设置为......在这里我卡住了，因为我不知道如何强制一张发票可以有多个 transactinos 但在一个匹配中（我猜这里我缺少关于匹配的信息）
我想我会在发票和交易表中添加一个额外的列。并且当用户进行匹配时，我会将唯一的数字（但对于匹配是唯一的，对于表而言不是唯一的）到这些列。这个号码将是匹配号码，我可以很容易地检查女巫的交易/发票是否被检查过。

这是我目前最好的想法。但正如我所说 - 我不确定这是否是最好的，所以我也请求您对此发表意见。

还有一件事：有一个类似的（乍一看）问题here，但问题是：

【问题讨论】：

“一张发票可以匹配多笔交易，一笔交易可以匹配多张发票。”你确定吗？当我从亚马逊订购东西时，我很确定没有其他人为此买单。（也就是说，我的交易只出现在我的发票上，不会出现在其他人的发票上。）
是的，因为所有交易/发票都是针对同一个用户——我们。所以所有的发票都是我们开的发票，所有的交易都是到我们账户的交易。

【解决方案1】：

如果一个事务可以匹配许多发票，而一个发票可以匹配许多事务，则没有直接的方法可以“锁定”这些行，以便它们一旦使用就不能再使用。

例如，如果您将 2 张发票与 3 笔交易匹配，则每笔交易将引用 2 张发票，每张发票将引用 3 笔交易。

没有直接的方法告诉 SQL Server：“伙计，我们已经完成了，不要再匹配这些行了！”。那是因为你不能为它定义规则。

一旦您知道不可能创建此规则，解决问题的最简单方法就是使用您的应用程序逻辑和此数据库设计来实现它：

然后，其余的工作必须从您的应用程序逻辑中完成：

这是一个简单、易于实施且清晰的解决方案。遵循 KISS 原则。

为每个匹配组创建一个数字，即中间表上的第三个标识列，可以在还原更改或查询匹配组时为您提供帮助，但这不是必需的。

【讨论】：

嗯，我认为你的答案是完整的。但我将坚持我的最后一个想法，创建额外的列并在那里放置与否匹配的数字。这样我将避免额外的表。当然，您的解决方案更好地标准化，但另一方面，我的解决方案对我来说更明显:)。不过还是谢谢！
由于您没有使用“规范化版本”，您应该在这些数字列上创建索引。相反，每当您要查询这些列或加入该列上的表，或按该列过滤时，系统将不得不进行全表扫描。如果您使用“规范化解决方案”，则索引将已经存在于中间表上。并不是说您的解决方案很糟糕，特别是如果它对您更有意义，但请考虑到这个微小的细节。
好点，谢谢。我会记住这次旅行，因为这绝对是有意义的。