Question

帮助！

如果我在项目中使用动态SQL或代码重复，或者我的整个过程完全不正确，我会遇到问题。

首先 - 下面的例子不正确，我已经简化了很多，以避免过于冗长的讨论，确切地说是发生了什么。

前提：我有大量的人必须链接到我无法控制的地址表。我把它们连接到这个地址表要么根本没有（null）因为我在地址表中找不到正确的地址或我将它们链接到建筑物（但如果它是公寓楼则不是公寓）因为它在大楼的公寓和我得到的地址没有（或不正确）的公寓信息。或者，最后，我将它们100％链接到公寓（完全正确的匹配）。

由于地址表经常使用有关地址的新信息进行更新，因此我必须尝试重新匹配空值并构建匹配以完全正确匹配。匹配逻辑在几个存储过程中非常广泛。

现在......当我为人员表传入（新）People时，我首先将它们存储在IncomingPeople表中，以便能够处理该表中的所有匹配（聪明的？）然后只是“倒”这些（已经匹配到今天我能做的好了）人们进入人员表。传入表还包含应该使用Date变量添加到people表中的人员，因此我不会添加直到稍后才开始的人员。

但是！（在这里它来了）当我需要看看我是否可以重新匹配在人员数据库中为null或构建匹配的人时，我无法在People表上运行复杂的匹配逻辑，因为它非常巨大且匹配的逻辑是太复杂了。

我的想法是将人们从People表中移出到另一个尚未匹配的表（此处称为RematchingPeople），然后在该表上执行匹配逻辑，然后使用正确的addressID更新People表（如果有）改变。

所有这一切都很好，没问题。但我需要复制复杂的匹配代码才能在IncomingPeople表和RematchingPeople表中工作（当前方法，但我们不时更改匹配逻辑，在两个地方更新都很麻烦）或使用动态SQL，但我这样做有点小心 - 我错了吗？这是动态SQL非常棒的时代之一吗？我应该这样做并且乐意它存在吗？

People
(
    id int,
    name varchar(200),
    address varchar(200),
    postalcode int,
    city varchar(100),
    addressID bigint
)

IncomingPeople
(
    name varchar(200),
    address varchar(200),
    postalcode int,
    city varchar(100),
    startdate date
)

RematchingPeople
(
    id int,
    name varchar(200),
    address varchar(200),
    postalcode int,
    city varchar(100),
    addressID bigint,
    IsReMatched bit
)

为可读性而编辑

Answer 1

据我了解，您的IncomingPeople表充当队列。 RematchingPeople也像一个试图获得更好匹配的队列。

我会考虑在人员表和RematchingPeople表中使用match_type和/或match_strength字段。这为您提供了一种机制，可以确定您当时达到的匹配程度，从而缩短任何重新匹配活动，以便您以后只尝试更强的匹配。

我会考虑将sp_ExecuteSQL与动态SQL一起使用，因为所描述的情况适用于结构非常相似且不太可能更改的表。

在清除RematchingPeople队列表方面，您可以为人员表制定更新条件，其中RematchingPeople表中的match_type和/或分数超出或匹配人员表的匹配。删除条件将删除其匹配类型或分数小于或等于人员表格的RematchingPeople。

我不清楚的是，您的IncomingPeople表是否可以接收您之前可能已加载的人员以及是否可以将传入人员的密钥保存到People。如果您无法将相同的人员作为新人提交，那么您可以通过向IncomingPeople添加match_type和/或分数以及简单地将人们推回IncomingPeople队列来弃用您的RematchingPeople表。

动态SQL与代码重复

1 个答案: