IDという名前のフィールドを使用します。整数の主キー。一部のIDフィールド/関係が混乱した場合にテーブルを再構築できるように、2番目の一意のフィールドも指定することは重要ですか、それとも心配ではありませんか？
Sql-CEデータベースで自動インクリメント整数を使用しています。シングルユーザー。
5 に答える
3
テーブルのセマンティクスで必要な場合は、必要に応じて一意のキーをいくつでも追加します。たとえば、問題のドメインですべての「従業員」エンティティがNameによって一意に識別される場合、Nameには一意のインデックスまたは制約が必要です。同じ名前の従業員が2人いる可能性がある場合は、もちろん、その列に一意性の制約はありません。
現在、学校ごと、会計年度ごとに情報を保持する必要があるクライアントがいます。学校と年の列を組み合わせた一意の制約（またはインデックス）が必要です。これら2つが主キーでもある場合もありますが、主キーでない場合でも、これらは一意です。
于 2011-01-01T22:10:52.923 に答える
1
2番目の一意のIDフィールドを追加する動機がよくわかりません-何のために?? それからあなたが見る利益は何ですか？
必要なのは、ID一意で安定していて、個々の行を明確に識別でき、主キーとして機能できるINT IDENTITYものです。SQLServerではそれが完全にうまく機能します。
各行に2番目の一意のIDを追加してもポイントやメリットはありません...
于 2011-01-01T22:03:54.430 に答える
1
すべてのテーブルには、1つ以上の候補キーがあります。主キーとなるものを1つ選択してください。セマンティックの正確さを強制するために、他にUNIQUE制約を追加します。何かが「台無し」になった場合にテーブルを再構築できることとは何の関係もありません。
また、アクセスをできるだけ速くするために、WHERE句に表示される列にインデックスを付ける必要があります。これらはアプリケーション/ユースケース固有です。
私が意味する例は、アドレステーブルです。代理主キーがある場合があります。SELECTを効率的にするために、zip、市、州、郡などのさまざまな組み合わせのインデックスも用意します。また、street1 / street2 / city / Province/zipの組み合わせをUNIQUEにすることもできます。あなたのビジネス上の問題に依存します。
于 2011-01-01T22:06:35.807 に答える
1
テーブルには、データの整合性に耐えるのに必要な数のキーが必要です。この場合の「ID」が代理キーを意味する場合、答えは「はい」です。通常、適切に正規化されたデータベースで一意性を確保するために自然キーが必要です。そうでない場合、意味のあるビジネスデータを複製する可能性があります。自然キーの前に代理キーを特定している場合は、設計に欠陥のあるアプローチを取っていると思います。
キーを選択するための適切な基準は、親しみやすさ、シンプルさ、安定性です。考えられる不利な点と追加の複雑さを考慮して、正当な理由がある場合にのみ、モデルに代理キーを追加します。
于 2011-01-02T04:07:31.417 に答える
1
バックアップのための冗長性は、価値のある設計になる可能性があります。
ただし、ほとんどの人は、質問が示すように、冗長な列をスキーマテーブルにロードすることによってそれを実装しません。そのようにすることには多くのオーバーヘッドがあり、メインIDが台無しになると同時に重複IDが台無しになる多くの障害モードがあります。
限られた期間にわたってIDの履歴を追跡する履歴テーブルを設計する方がよい場合があります。多くの人が履歴テーブルをオフラインストレージのステージング領域として設計し、データベースには最近の履歴のみが保持されます。この種の歴史は、あなたが興味を持っている問題に加えて、他の問題に取り組むことができます。
于 2011-01-02T14:17:12.793 に答える