5

私の会社は現在、最近取得したアプリケーションを書き直している最中です。ASP.net mvc4 を使用してこのシステムを構築し、エンティティ フレームワークを ORM として使用することにしました。私たちが買収した会社の前の所有者は、私たちが古いデータベースを使用し、それについて何も変更しないことを非常に強く主張しています。これにより、私たちがさまざまなモジュールを開発している間、クライアントは古いシステムと同時に私たちの製品を使用できます.

古いテーブル構造には主キーがなく、一意のインデックスを使用して主キーとして機能することがわかりました。エンティティ フレームワークを使用する場合、テーブルの構造を一致させようとしましたが、EF が一意のインデックスではなく主キーを生成するため、一致させることができませんでした。

以前の所有者に連絡して説明したところ、「すべてのテーブルの一意のキーは主キーです。それらは互いに同義語です」とのことでした。

私はまだデータベースシステムに比較的慣れていないので、これが正しいかどうかわかりません。誰でもこれを明確にできますか？

彼のテーブルを SQL にダンプすると、次のように生成されます。

-- ----------------------------
-- Indexes structure for table AT_APSRANCD
-- ----------------------------
CREATE UNIQUE INDEX [ac_key] ON [dbo].[AT_APSRANCD]
([AC_Analysis_category] ASC, [AC_ANALYSI_CODE] ASC) 
WITH (IGNORE_DUP_KEY = ON)
GO

ただし、私のシステムは次を生成します：

-- ----------------------------
-- Primary Key structure for table AT_APSRANCD
-- ----------------------------
ALTER TABLE [dbo].[AT_APSRANCD] ADD PRIMARY KEY ([AC_Analysis_category])
GO

編集: これに対するフォローアップの質問は、このためにモデルを設計するにはどうすればよいですか? 私は主キーとして定義する [Key] 注釈の使用に慣れているだけで、それがなければ EF はそのテーブルを生成しません。このようなもの：

[Table("AT_APSRANCD")]
public class Analysis
{
    [Key]
    public string AnalysisCode { get; set; }
    public string AnalysisCategory { get; set; }
    public string ShortName { get; set; }
    public string LongName { get; set; }
}
4

6 に答える 6

5

SQL UNIQUE 制約から

UNIQUE 制約は、データベース テーブル内の各レコードを一意に識別します。

UNIQUE 制約と PRIMARY KEY 制約はどちらも、列または列セットの一意性を保証します。

PRIMARY KEY 制約には、UNIQUE 制約が自動的に定義されます。

テーブルごとに多数の UNIQUE 制約を設定できますが、テーブルごとに 1 つの PRIMARY KEY 制約しか設定できないことに注意してください。

また、一意のインデックスの作成から

列の複数の行に NULL が含まれている場合、単一の列に一意のインデックスを作成することはできません。同様に、列の組み合わせの複数の行に NULL が含まれている場合、複数の列に一意のインデックスを作成することはできません。これらは、索引付けのために重複値として扱われます。

一方、主キーの作成から

PRIMARY KEY 制約内で定義されるすべての列は、NOT NULL として定義する必要があります。nullability が指定されていない場合、PRIMARY KEY 制約に参加しているすべての列の nullability は NOT NULL に設定されます。

于 2013-09-26T06:34:25.850 に答える
4

彼らは間違いなく違います。他の回答で述べたように：

  • 一意のキーは、一意性をテストするためだけに使用され、他には何も使用されません
  • 主キーは、レコードの識別子として機能します。

また、重要なことは、通常、主キーがクラスター化インデックスであることです。これは、レコードが主キーによって定義された順序で物理的に格納されることを意味します。これはパフォーマンスに大きな影響を与えます。

また、クラスタ化されたインデックス キー (ほとんどの場合、主キーでもあります) は、他のすべてのインデックスに自動的に含まれるため、取得するのにレコード ルックアップは必要なく、インデックスを読み取るだけで十分です。

要約すると、テーブルに主キーがあることを常に確認してください。インデックスはパフォーマンスに大きな影響を与えるため、適切なインデックスを作成する必要があります。

于 2013-09-26T06:47:03.563 に答える
3

それらは確かに同じものではありません。

主キーは一意である必要がありますが、これは要件の 1 つにすぎません。もう1つは、一意の制約には必要ないnullにできないことです。

また、ある意味では、一意の制約は貧弱な人の主キーとして使用できますが、それらを一緒に使用することIGNORE_DUP_KEY = ONは明らかに間違っています。この設定は、重複を挿入しようとすると、挿入がサイレントに失敗することを意味します。

于 2013-09-26T06:40:09.820 に答える
2

まあ、それらは非常に似ていますが、違いは次のとおりです。

1 つのテーブルで許可される主キーは 1 つだけですが、複数の一意のインデックスをテーブルの最大許容インデックス数まで追加できます (SQL Server = 250 (1 x クラスター化、249 x 非クラスター化)、SQL 2008 および SQL 2012 = 1000)。 (1 x クラスター化、999 x 非クラスター化))。主キーには null 許容列を含めることはできませんが、一意のインデックスには含めることができます。許可される NULL は 1 つだけであることに注意してください。インデックスが複数の列にわたって作成される場合、値と NULL の各組み合わせは一意である必要があります。

既定では、create ステートメントで特に指定しない限り、クラスター化インデックスがまだ存在していなければ、主キーはクラスター化インデックスとして作成されます。ただし、一意のインデックスは、特に指定しない限り、クラスター化されたインデックスがまだ存在しない限り、デフォルトで非クラスター化インデックスとして作成されます。

次のリンクは本当に役に立ちます。

ここ

于 2013-09-26T06:35:20.903 に答える
1

はい、ここにあるような複合キーと一意キーは、主キーと非常によく似たインデックスを提供します。これらの利点の 1 つは、データがインデックスに含まれているため、キー内のフィールドのみを照会する場合は、テーブルを検索する必要がないことです。

これは Entity Framework でも可能です。それは次のようになります。

public class AT_APSRANCD
{
    [Column(Order = 0), Key, ForeignKey("AC_Analysis_category")]
    public int AC_Analysis_category{ get; set; }

    [Column(Order = 1), Key, ForeignKey("AC_ANALYSI_CODE")]
    public int AC_ANALYSI_CODE{ get; set; }
}
于 2013-09-26T06:38:22.063 に答える
0

主キーに null 値が含まれていません。

ただし、一意の null 値の場合、テーブルに挿入できます。

任意の数のnull値を挿入できます

主キーの定義PRIMARY_KEY=UNIQUE+NOT_NULL

于 2013-09-26T06:45:59.790 に答える