動的SQLとコードの重複

Question

Help！

プロジェクトで動的SQLやコードの重複を使用する必要がある場合や、プロセス全体が完全に間違っている場合は、問題があります。

まず、以下の例は正しくありません。何が起こっているのかについての長すぎる議論を避けるため、かなり単純化しました。

前提：管理していないアドレステーブルにリンクする必要がある人が非常に多いです。アドレステーブルに正しい住所が見つからないため、このアドレステーブルにリンクしています（ヌル）。または私はそれらを建物にリンクしますが（アパートの場合はアパートではありません）、私が持っている住所はアパート情報がない（または間違っていた）。 最後に、私は100％それらをアパートにリンクします（完全に一致します）。

アドレステーブルは、アドレスに関する新しい情報で頻繁に更新されるため、完全一致の完全一致のためにnullを再一致させ、一致を構築する必要があります。 マッチングロジックは、いくつかのストアドプロシージャで非常に広範囲です。

Now ...私のPeopleテーブルの受信者（新規）を持っているときは、最初にIncomingPeopleテーブルに格納して、そのテーブルのすべてのマッチングを処理できるようにします（スマートehe？）。 （私は今日できるようにすでに一致しています）人々は人のテーブルに。また、入ってくるテーブルには、将来、人のテーブルにDate変数を追加する必要がある人もいるので、後で開始する人は追加しません。

しかし！ （そしてここに来る）私は人がデータベースに一致するnullまたはビルドされた人々を再一致させることができるかどうかを知る必要があるとき私は非常に巨大で一致するロジックはPeopleテーブル上で複雑なマッチングロジックを実行できませんとても複雑です。

私の考えでは、Peopleテーブルの人を、まだマッチしていない別のテーブル（ここではRematchingPeople）に持ち上げて、そのテーブルで一致するロジックを実行し、Peopleテーブルを正しいaddressIDで更新しました変更されました。

これはすべて問題なく動作します。しかし、私はIncomingPeopleテーブルとRematchingPeopleテーブルの両方で動作するように複雑なマッチングコードを複製する必要があります（現行の方法ですが、時には一致ロジックを変更して、両方の場所で更新するのが面倒です）それを少し気にしています - 私は間違っていますか？これは、動的SQLが本当にすばらしい時代の1つです。私はそれを実行して、それが存在するのを幸せにする必要がありますか？

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 
) 

私はそれがあなたのIncomingPeopleテーブルがキューとして機能している理解したよう可読性

Answer 1

のために編集されました。 RematchingPeopleは、より良い一致を試してみるためのキューのようなものです。

あなたの人物テーブルとあなたのRematchingPeopleテーブルにmatch_typeおよび/またはmatch_strengthフィールドを持つことを検討します。これは、あなたがその時点で達成したマッチをどれだけ優れているかを識別するメカニズムを提供し、したがって、再認証アクティビティを短絡させるので、将来的により強いマッチを試みるだけです。

非常に似た構造を持ち、変更される可能性が低いテーブルの場合、説明したように、動的SQLでsp_ExecuteSQLを使用することを検討します。

RematchingPeopleキュー表をクリアすることで、RematchingPeople表のmatch_typeおよび/またはスコアがpeople表の一致基準を超えているか、または一致している、従業員表の更新基準を作成できます。削除基準によって、match_typeまたはscoreがPeopleテーブルのスコア以下であるRematchingPeopleが削除されます。

IncomingPeopleテーブルには、以前にロードした可能性のある人物と受け取った人物のためのキーをPeopleに永続化できるかどうかは不明です。同じ人が新しい人物として提出されないようにするには、Match_typeおよび/またはスコアをIncomingPeopleに追加し、人をIncomingPeopleキューに戻すだけで、RematchingPeopleテーブルを非推奨にすることができます。