1

MySQL データベースに保存および更新する必要がある企業のディレクトリが提供されています。各企業レコードには、企業番号 1234 などの一意の識別子はありません。

フィールドは、メーリング リスト、連絡先名、会社名、番地、都市、州、郵便番号、電話番号、および会社の種類の典型的なものです。更新は CSV ファイルとして送信されますが、会社固有の ID 番号はありません。

データベースに保存されているレコードを新しいレコードと照合して、更新できるようにするにはどうすればよいですか? この業界では、パートナーを追加および削除するため、連絡先の名前が変更される可能性があり、会社名も変更される可能性があります。ビジネスを移転すると住所が変わる可能性があり、電話番号も変更する可能性があります。ほとんどの企業は Web サイトの URL を持っているため、頻繁に変更されることはないことを願っていますが、簡単に変更される可能性もあります。

MySQL で同様の一致 % があるのを見たことがありますが、これはレコードを新しい情報と一致させるための答えでしょうか?

PHP ソリューションがあれば、私は PHP で作業します。これを手伝ってくれる親切な魂に前もって感謝します！

4

5 に答える 5

2

主キーがないと、常に注意が必要です。

1 行のソリューションで、要件に最適なルールを決定します。

私があなただったら、まずクライアントのところに行き、類似の記録を特定するためのいくつかのルールを決定します。エントリが重複したり間違ったレコードを更新したりする可能性が常にあるため、この手順は主キーがない場合に必要です。

ルールは次のように単純です。

1. Available fileds:
    contact name,
    company name,
    street address,
    city,
    state,
    zip code,
    phone number and
    type of company (I Hope this is industry)
2. We will first match company name for similarity like
    select * from table_name where company_name like '%$company_name%'
3. For all found records, match zip code and phone number. If match, break, record needs to be updated
4. If not match found in step 3, match street address. If match, break, record needs to be updated
5. & so on.

クライアントは製品の所有者であるため、これらのルールを決定するのに最適な人物です。

一方、主キーがない場合でも、すべての注意を払った後でも、レコードが重複したり、間違ったレコードを更新したりする可能性が常にあるため、クライアントにルールを尋ねることも安全を確保するために重要です。良いルールでチャンスを最小限に抑えることができます。

于 2012-09-25T06:24:21.313 に答える
1

テーブルのすべてのフィールドが変更される可能性があるとおっしゃっていましたが、どのアルゴリズムを選択しても、毎回テーブルを正しく更新する簡単な方法はないと思います。
これを実現する方法の1つは、（更新されたレコードを送信する）人/システムに、更新されたフィールドの古い値もcsvファイルに含めるように依頼することです。古い値がある場合は、それらを現在のレコードと簡単に照合し、新しい値で更新できます。

于 2012-09-25T06:49:51.867 に答える
0

これはかなり一般的な質問ですが、ソリューション自体はプロジェクトごとに多少異なります。

変更時（または作成日や更新タイムスタンプなど）順に並べられたすべてのレコードを繰り返し処理します。次に、会社名、住所（リスクがあるかもしれませんが）、電話、またはURL（ドメインの解析のみ）などの主要なフィールドを持つすべてのエントリを照合します。次に、結果が見つからなくなるまで、見つかったすべてのエントリを再帰的に繰り返します。

このアルゴリズムは、すべての主要な列が一度に変更されない限り、同じエントリを見つけるのに役立ちます。もしそうなら、それがプログラムで同じ会社であると言う方法はありません。

これにより、行が一見接続されているように見えます（例では行1と3）

例：

2001/01/01 Awesome firm, awesome.com
2002/02/02 Awesome firm, newaddress.com // linked with the first row over company name
2010/12/05 Ohsome inc, newaddress.com // linked over url
于 2012-09-25T06:10:29.203 に答える
0

Damerau-Levenshtein距離アルゴリズムを見てみましょう。2 つの文字列間の「距離」を計算し、1 つの文字列を別の文字列に変換するのに必要なステップ数を決定します。ステップが少ないほど、2 つの弦は近くなります。

この記事では、MySQL ストアド関数として実装されたアルゴリズムを示します。 PHPのバージョンはこちら。

このアルゴリズムは、LIKE や SOUNDEX よりもはるかに優れています。

于 2012-09-25T06:18:03.877 に答える
0

Sqlサーバーでの以前のプロジェクトの1つで、少し似たシナリオが発生しました。これを処理するために、次のことを行っていました。

1.通常、2種類のファイルがあります--

a) フル フィード (毎週の頻度) これには、プロバイダー データベースからのすべての企業が含まれます。増分フィードのフラグとして）

2.したがって、完全なフィードを受信したら、データベース テーブルを週に 1 回、完全なフィードで更新します。また、ここでは、各企業レコードの内部 ID を取得します (これらの ID は内部目的のためのものです)。

3.毎日、フラグ (I-挿入、U-更新) に基づいてインクリメンタル フィードを処理します。

4.ここで非常に重要なことの 1 つは、マッピング テーブルを管理することです。フィードが来たら、新しい内部 ID を割り当てるだけです。

5. 重複を避けるためにデータを比較するために、以前はファジー アルゴリズムを使用して潜在的な一致をすべて取得し、次にワイルドカード文字を使用してフィルタリングし、どれが新規で重複しているかを識別していました。

于 2012-09-25T06:16:31.803 に答える