重複するレコードを追加している可能性があることをユーザーに伝える方法
ユーザーが新しい連絡先レコードを追加できるフォームがあります。複数のユーザーがすべて同じフォームを使用しているため、ユーザー[〜＃〜] abc [〜＃〜]がそのユーザーと同じ連絡先レコードを追加しようとする可能性が高い[〜＃〜 ] def [〜＃〜]はすでに追加されています。
したがって、この状況に対処する方法はいくつかあります。
追加する前に重複する連絡先をチェックできるように、「連絡先の追加」ページの前に検索オプションをユーザーに与えます。
ユーザーが連絡先の詳細を追加できるようにし、フォームへの入力中にフィードバックを提供します。追加したデータに応じてユーザーに警告を表示します（以下のUIを参照）。ユーザーは警告を無視して詳細を追加し続けることができます。「連絡先を保存」ボタンをクリックして、連絡先がすでにシステムに存在するために追加できないことがわかります。
download bmml source – Balsamiq Mockups で作成されたワイヤーフレーム
質問：この問題を解決するための最良のアプローチは何でしょうか？オプション1または2、あるいはその両方の組み合わせ、または他の何か？
ユーザーがシステムに追加しているレコードの名前と姓を検証しない理由を理解しようとしています。
基本的に、これは有効なシナリオとしては表示されません。どのシステムでも同じ姓と名を持つユーザーが存在する可能性があるためです。従業員数が1,000人の小規模な組織でも、姓名は多くの従業員と競合します。
ユーザーに一意のユーザーIDを与え、ユーザーIDに検証を適用することをお勧めします。ユーザーが重複するユーザーIDを選択した場合、検証メッセージを次のように表示します。
さらに、携帯電話番号は一意であるため、携帯電話番号（フォームにそのオプションがあります）に検証を適用できます。
フォームに入力したら、同様の連絡先がすでにシステムに存在することを示す通知を表示します。これらの各連絡先の概要を表示し、ユーザーがそれらの既存の連絡先の1つを選択する（連絡先の情報を新しい情報で更新する可能性がある）か、新しい連絡先の作成を続行できるようにします。
とても簡単な方法があります。まず、複製できるデータと複製できないデータについて考えてみましょう。
他の回答が述べたように、Name（最初、最後、または両方の組み合わせ）は、多くの繰り返し名がある可能性があるため、適切な選択ではありません。
だからあなたはモバイルを持っています。これは、イントラネットで機能するか、アプリが地理的に制限されている場合（たとえば、1つの都市のみ）で機能します。それ以外の場合は、携帯電話番号NNN-NNNNBig Cityの誰かのためにNNN-NNNNSmall Cityの誰かのために。 「OK、市の接頭辞で検証しましょう」と言うかもしれません。次に、携帯電話番号NNN-NNN-NNNN inUNicornCountry、次に携帯電話番号NNN-NNN-NNNN inRainbowCountry。さらに悪いことに、すべての国が同じ桁数を持っているわけではないので、これも明らかに良い選択ではありません。
しかし、絶望しないでください！検証が非常に簡単なフィールドがあり、確認に使用でき、繰り返すことはできません：email。 同じメールは2つ存在できないため、これは最適な選択肢です。
これを念頭に置いて、物事をスムーズに実行させることができます。下の画像を確認してください（拡大する必要がある場合はクリックしてください）。
それはこれと同じくらい簡単です：
既存のアカウントの場合にユーザーが不要なフィールドに入力しないように、最初のフィールドとしてメールを追加します。
システムはメールが重複していないかどうかを確認します
メールが重複している場合は、ユーザーに自分のアカウントにアクセスするオプションを提供します。
3b。重複していない場合は、アカウントを作成し、メールアカウントの確認を求めることができます
そしてそれだけです。シンプルで要領を得ています。
一意の名前に基づいて検証しないことをお勧めします。データベースに同じ名前の2人が存在する可能性があるためです。
電話番号の検証は、通常、電話番号が一意で複数の人が共有していない場合と同様に機能しますが、これが固定電話の場合、複数のユーザーが同じ番号を共有している場合があります。ユーザーが重複した番号のエントリを追加しようとした場合に警告を表示するのが最も賢明かもしれませんが、フォームが送信された場合は許可します。
また、AJAXをあなたの姓と名のフォームフィールドに追加して、フォームの入力時に一致するユーザーを表示することもできます。たとえば、John Smithを追加して、サイドは、ジョンスミスが私が入力しようとしている電話番号とともに存在することを示しています。私は彼がシステムに存在し、彼を追加する必要がないことを知っています。
完全一致一致（自然キーによる）
作成しようとしているレコードのタイプに Natural Key が存在するかどうかによって、アプローチは根本的に異なります。
自然キーとは、実世界にすでに存在するデータを一意に識別するものです。たとえば、レコードに社会保障番号、ISBN、Active Directoryアカウント、または時々メール/電話が含まれている場合、各レコードに個別のキーがあることを保証することで、重複を防ぐことができます。
たとえば、これはTwitterのサインアップページです。
注1：検証エラーと同様に、データの状態が無効な場合は インラインですぐに実行することをお勧めします です。したがって、不必要な入力を避けるために、ステッパーページまたは別のページのいずれかで、最初に固有の情報を要求する必要があります。
注2：可能性があることを覚えておいてください[〜＃〜]ではない[ 〜＃〜]連絡先レコードの一意の識別子として電子メールまたは電話を使用したい（たとえば、複数の専門家がすべてビジネス用連絡先の電子メールと電話番号を共有できる）。
注3：あなたができる間は、username、これは実際には、生成された名前以外の重複を防ぐためのメカニズムではありません。
たとえば、これはRedditのサインアップページです。
これは、入力時に検証エラーを動的に表示するのに最適です。ただし、同じユーザー、個人、個人でも、ほぼ同じアカウントを作成できます。実際の意味を持つ識別子を生成しましたが、アカウントを区別するためだけに使用でき、人には使用できません。
類似一致
複数のフィールドを使用してレコードを確立する場合[〜＃〜] and [〜＃〜]本物のレコードは、フィールド全体で情報を繰り返すことができます（つまり、同じ姓+姓+ DOB）。次に、システムが実行できる最善の方法は、重複の量とテクノロジーを最小化することです。そのビジネスプロセスで役割を果たすことができます。
今問題は次のようになります：
新しいレコードを作成するプロセス中に、ユーザーに類似したレコードのリストを表示するのに最適なタイミングはいつですか？
オプション1-同期/モーダルマッチ
重複する可能性のあるものを同期的に提示する場合、着信レコードについて知るのに十分な情報を収集してから、続行する前にユーザーに潜在的な一致を確認させる必要があります。
たとえば、My Fitness Palに新しい食品を追加する手順は次のとおりです。
注1：ユーザーが新しいレコードの作成に進む場合は、検索パラメーターを新しいアイテムにシードして、同じものを入力する必要がないようにする必要があります。情報を2回。
注2：プログラムでレビューを実施する強さは、実際のシステムからの重複とユーザーテレメトリの重大度によって異なります。たとえば、実際の作成手順（多くのサイトのTOC契約など）に進む前に、それぞれを強制的にスクロール/レビューすることができます。
注3：プログラムで重複の可能性を識別する場合は、必ず タイプミス、ニックネーム、代替スペルを確認してください も確認してください。
オプション2-非同期/モードレスマッチ
このアプローチは、ハッピーパスを想定しており、ユーザーがレコード情報の入力をすぐに開始できるようにします。これらの情報はすべて、潜在的な一致を非同期で識別するために使用可能になります。
たとえば、Stack Overflowについて質問する手順は次のとおりです。
注1：潜在的な一致（または新しいコンテンツ）をページに動的に挿入する場合、コンテンツは現在のページ位置の右または下に来る必要があります。コンテンツがジャンプするのを防ぎ、ユーザーがページの前の部分に戻る必要がないようにします。
同期チェックと非同期チェックのどちらを選択するかについては、ユーザーが重複を作成せずに新しいレコードを正常に追加する頻度のデータを確認することをお勧めします。 80％の確率でユーザーが一意のレコードを作成する場合、重複チェックのボトルネックを介してそれらすべてを強制することは、追加の問題点であり、不必要なコンテキストシフトです。
画面に入力した情報をユーザーが実際に読むことを強制するものは何もないため、目標は、時間を節約するのに役立つ便利な画面に何かを置くことです。そしてそうすることは多くのノイズなしで本当に良いマッチングアルゴリズムを必要とします。
De重複レコード-ジャーニーマッピング
これがあなたのビジネスにとって重要な機能である場合、このニーズは他の複数の対話ポイントでも対処できることを覚えておいてください。確かに、作成中に対処しても問題はありません（ [〜＃〜] gigo [〜＃〜] ）が、手動でdeduplicate事後に同様に次の機能を備えています：
個人ユーザー
Googleの連絡先に従って、ユーザー自身のデータ品質を確認する力をユーザーに与えます：![Google Contacts - Find Duplicates]()
コミュニティレポート
Untappdのように、ユーザーからコンテンツをクリーンに保つように依頼してください（wikiモデル）：![Untappd - Propose Duplicates]()
モデレートレビューキュー
Stack Exchangeのように、管理者がシステム全体の重複を確認するようにします。![Stack Overflow - Queues]()
参考文献：
オプション1は良い考えですが、これらの画像では、検証のために姓と名を表示しているため、同じ名前を持つ一部のユーザーを防ぐことができます。 2人のユーザーが同じ携帯電話番号を持つことはできないため、モバイルレコードに検証の検証を追加します。
この回答は、これらの画像に示されているフィールドに基づいています。ユーザー名がある場合、ユーザー名が主要な最初の検証ポイントになる可能性があります。ユーザーにすべての作業を依頼するため、ライブインライン検証の方が適しています。
以下のリンクをお読みください： https://baymard.com/blog/inline-form-validation
ユーザー名指向の一意のIDを持つWebサイトには、ユーザー名の単一フィールドがあり、名前と姓が単一フィールドに提供されます。ユーザー名がすでに取得されている場合は、ページをリロードせずにajax検索を使用してすぐに表示されます。
姓と名のオプションがあるウェブサイトには、電話番号やメールアドレスなど、重複してはならない他の一意のIDがあると思われます。これらの種類のサイトは、多数のユーザーが共通の名前を共有するソーシャルネットワーキングサイトですただし、電話/メールIDが異なります。