一意の複合キーを作成するために必要な最小限のフィールドセットをプログラムで見つける
さまざまなソースからフラットファイルをSQL Serverのテーブルにインポートしています。すべての行に一意のキーを提供する抽出からのフィールドの組み合わせを使用して、複合主キーを作成しています。
今は、1つのフィールドから始めて、すべてのレコードで一意のキーが見つかるまでフィールドを連結し続けます。これには少し時間がかかる場合があります。または、一意のキーを取得するために実際に必要な数よりも多くの列を連結する可能性があります。
一意のキーを取得するために連結する必要があるフィールド（名前）の最小数を取得できる、ある種のSQLスクリプトをテーブルで実行できますか？したがって、すべてのレコードに対して一意であるテーブルに1つのフィールドがある場合、その1つのフィールド名が返されます。一意のキーを取得するために[memberid]、[claimid]、および[date of service]を連結する必要がある場合、これらの3つのフィールド名がスクリプトの結果になります。
すべての行に一意のキーを提供する抽出からのフィールドの組み合わせを使用して、複合主キーを作成しています。
ええと、これは主キーの目的とは厳密には一致しません。はい、それらは各行を一意に識別しますが、兄弟および子テーブルへのサポート関係の基礎でもあります。
一意のキーを取得するために連結する必要があるフィールド（名前）の最小数を取得できる、ある種のSQLスクリプトをテーブルで実行できますか？
キーや一意のインデックス、または一意の制約が定義されていないテーブルにデータを読み込んだり、PKまたは一意の（インデックス|制約）を作成したりするなど、わずかに異なる形式であっても、すでに行っていることの外側ではないフィールドのさまざまな組み合わせについて。どちらの場合も、おそらく最初からこれを行うべきではありません。
このアプローチには一般にいくつかの問題があります。
- 一意性にいくつかのオプションがある場合はどうなりますか？ 1つ以上の個々のフィールドの任意の組み合わせおよび/または複数のフィールドの1つ以上のセット？
FieldAは一意である可能性があり、FieldD+FieldHは一意である可能性があります。それで？ - 個々のフィールドまたはフィールドの組み合わせが一意でない場合はどうなりますか？すべてのフィールドを使用しても独自性が得られない場合の計画は何ですか？
- インポートプロセスの不良データやエラーについてはどうですか？受信データをスキャンすることは、最初にデータをどれだけ信頼できるかわからないため、エラーが発生しやすくなります。受信データが良いか悪いかをシステムがある程度理解している必要があります。外部システムのエクスポートプロセスのバグと同じくらい簡単にバグになる可能性のあるものについてビジネスルールに基づいているだけではありません（それはneeeeeeeverが発生する;-)。
- これらのインポートテーブルのいずれかが相互に関連していますか？その場合、プログラムで一意性を見つけようとすると、関連しているはずのテーブルの異なるフィールドが選択される可能性がありますが、少なくとも1つのテーブルのフィールドの複数の組み合わせで一意性が見つからないため、互換性のない組み合わせが共感できる組み合わせ。
- 型はどのように決定していますか？
0x02FB4C97はどうですか？それはVARBINARYまたは16進バイトの文字列ですか？123456はどうですか？それはINT、BIGINT、VARCHAR、DATETIME（ユリウス形式）、VARBINARY（先頭の0xなしでA-F決定に役立つ）？ - 1つ以上の列の「データ」が根本的に変化するとどうなりますか？現在空のフィールドがあり、それが文字列であると思われるが、実際にはまだ使用されていない日付フィールドである、または当然、あなたが見ている特定のエクスポートの
NULLである場合はどうなりますか？または、可変長列の最大長はどうですか？現在5桁の数字に使用している「コメント」フィールドについてはどうでしょうか。後で実際のコメントに使用し始めますか？ - 質問のコメントで@MaxVernonが言及したように、データが実際にどのように存在するかを管理するルールがわからないため、新しいデータが後から来るとフィールドの一意性が変わる可能性があります。
つまり、これは次のようになります。最初にPKを定義する実際の目標は何ですか。これによって何を達成しようとしていますか？ IDENTITYフィールドを追加して、インポートされたすべてのフィールド（すべてIDENTITYフィールドを除く）内の重複を削除しない理由はありますか？
最初にデータの本当の性質についてさらに詳しく知り、次に、データをどのように存在するかとは限らず、データと一致するキーと制約でデータを保持するテーブルを作成する必要がありますすべき存在。
コメントとsrutzkyは素晴らしいアドバイスを提供しますが、あなたの状況にぴったり合ったツールがあります。 SSIS Data Profiling Taskは、潜在的な主キー（複数の列の場合）を特定することを目的としており、データに関する他の多くの有用な洞察を提供します。
新しいSSISパッケージを作成し、タスクを追加してから、ウィザードのようなインターフェイスを使用してデータをプロファイルします。アクセス可能な場所に新しい出力ファイルを作成し、Quick Profile...を選択して、データベースと必要なテーブルから適切な情報をプロファイルします。
完了したら、パッケージを実行してコンポーネントに戻り、Open Profile Viwer...を選択してすべてのエキサイティングなデータを確認します。候補キーの考慮事項として最大7列が要求された場合（図には示されていません）、ツールは、3列のPKのファクトテーブルの1つに対して96％の一致を示しました。
明確にするために、ビジネスルールがデータの一意性を決定する必要があることは間違いなく同意します。一意性についてデータに適合する列の組み合わせを見つけたからといって、必ずしも意味があるわけではありません。 =）
このためのスクリプトがあるとは思わないでください。データを入力する前に決定/定義する必要があります。そうしないと、アプリケーションが機能しなくなる可能性があります。
通常、テーブルが一意であるためには1つのフィールドが必要です。 （NからMへの）2つの異なるテーブルリレーションをリンクするテーブルを作成する場合のみ、一意にするためにMキーとNキーの両方が必要です。例外はありますが、一意のキーを構成するフィールドを決定するのは設計者の責任です。データは大きくなる可能性があり、一意性も大きくなる可能性があります。