データベース; 1つまたは2つのユニークなフィールド？

Question

IDという名前のフィールドを使用します。整数の主キーいくつかのIDフィールド/リレーションシップが台無しになった場合にテーブルを再構築できるようにするには、2番目の一意のフィールドを指定することも重要ですか？

私は、Sql-CEデータベースで自動インクリメント整数を使用しています。シングルユーザー。

Answer 1

2番目のユニークなIDフィールドを追加するという動機は本当に分かりません。あなたはそれから何が得られるのですか？あなたが必要なもの

は、ユニークな安定した、と明らかに個々の行を識別することが可能であるととしての役割を果たすことができるIDあるご主キー - SQL ServerでINT IDENTITYが、その完全によくありません。

私は、各行に2つ目のユニークIDを追加することで任意のポイントまたはゲインが表示されない...

Answer 2

各テーブルには、一つ以上の候補キーを持っています。 1つを主キーに選ぶ。意味の正確さを強制するために他の制約にUNIQUE制約を追加する。それは、何か「混乱している」場合にテーブルを再構成できることとは何の関係もありません。

可能な限り高速にアクセスするには、WHERE句に表示される列にも索引を付ける必要があります。これらは、アプリケーション/ユースケース固有のものです。

私が意味するものの例は、アドレステーブルです。サロゲート主キーがある可能性があります。また、SELECTを効率的にするために、zip、city、province、countyなどのさまざまな組み合わせにインデックスを付けることもできます。 street1/stree2/city/province/zipの組み合わせをUNIQUEにすることもできます。あなたのビジネス上の問題によって異なります。

Answer 3

テーブルのセマンティクスで必要な場合は、必要に応じて多くのユニークキーを追加します。たとえば、問題のドメインですべての "Employee"エンティティがNameによって一意に識別されている場合、Nameにはユニークなインデックスまたは制約が必要です。同じ名前の従業員が2人いる場合は、その列には一意性の制約はありません。

私は現在、クライアントごとに学校ごと、会計年度ごとに情報を保持する必要があります。彼らは学校と年の列にユニークな制約（またはインデックス）を組み込む必要があります。時にはこれらの2つもプライマリキーですが、プライマリキーではなくてもユニークです。

Answer 4

テーブルには、データの完全性に耐えるのに必要な数のキーが必要です。このインスタンスの「ID」が代理キーを意味する場合、答えは「はい」です。通常は、適切に正規化されたデータベースで一意性を確保するための自然なキーを使用する必要があります。そうしないと、意味のあるビジネスデータを複製できます。ナチュラルキーの前にサロゲートキーを特定している場合は、設計に欠陥のあるアプローチを取っていると思います。

キーを選択するための良い基準は、親しみやすさ、シンプルさ、安定性です。考えられる欠点と複雑さを考慮して、正当な理由があるときに限り、代理キーをモデルに追加します。

Answer 5

バックアップのための冗長性は、価値のある設計になる可能性があります。

しかし、ほとんどの人は、あなたの質問が示唆するように、冗長な列をスキーマテーブルに読み込むことによってそれを実装していません。このような作業には多くのオーバーヘッドがあり、メインIDが不正になるのと同時に重複したIDが不正になってしまう多くの障害モードがあります。

限られた期間にわたってIDの履歴を記録する履歴テーブルを設計する方がよい場合があります。多くの人がオフライン記憶域のステージング領域として履歴テーブルを設計しており、最近の履歴のみがデータベースに保持されています。この種の履歴は、あなたが興味を持っているものに加えて、他の問題にも対処できます。