我对我在项目中遇到的问题有疑问。问题是关于DB的模型并且更精确：我如何能够模拟这种关系（起初我认为它将是简单的M：M，但是在一些想法之后它不是那么明显;））。我有一些想法，但也许有人会有更好的东西：）
我的问题是关于以下问题：
我有2张桌子。一个人得到了发票，第二个 - 交易。一张发票可以与许多交易匹配，一张交易可以匹配多张发票。我想允许用户进行一些匹配，以便他可以选择发票（一个或多个），挑选交易（一个或多个）并点击＆＃34;匹配＆＃34;。但点击＆＃34;匹配＆＃34;后，所有使用的记录（inovoices和交易）都不能再使用了。我的想法是：
使用标准关联表，但有3列：idIncoive，IdTransaction和匹配信息的唯一ID。并且给...带来了独特的限制因为我不知道怎么强迫一张发票可以有多个transactinos但是在一个匹配中（这里是我缺少的信息）匹配我想）
我以为我会在发票和交易表中添加一个额外的列。当用户进行匹配时，我会将这些列中的唯一数字（但对于匹配而言是唯一的，而不是表的sens唯一）。而这个数字，将匹配数字，我可以轻松chcek女巫交易/发票被检查和什么。
这是我现在最好的想法。但正如我所说 - 我不确定这是最好的，所以这里也是我要求你对此提出意见。
还有一件事：有一个类似的（乍一看）问题here，但问题是：
答案 0 :(得分：1)
如果交易可以匹配许多发票，并且发票可以匹配许多交易，则没有直接的方法可以“锁定”这些行，以便一旦使用它们就不能再使用它们了。
例如，如果您将2张发票与3笔交易相匹配，则每笔交易将引用2张发票，每张发票将引用3笔交易。
没有直接告诉SQL Server的方法：“伙计，我们已经完成了，不允许再匹配这些行了！”。那是因为你不能为它定义规则。
一旦您知道无法创建此规则，解决问题的最简单方法是使用您的应用程序逻辑实现它，并使用此DB设计：
Matched bit列然后，其余的工作必须从您的应用程序逻辑中完成：
Matched字段设置为1 这是一个简单，易于实施和清晰的解决方案。遵循KISS原则。
为每个匹配组创建一个数字，即中间表上的第三个标识列，可以在还原更改或查询匹配组时帮助您，但这不是必需的。