4

「日付制限」というテーブルがあり、基本的に次のプロパティを保持しています。

DayId    : int
DateFrom : datetime
DateTo   : datetime
EventId  : int       // this is a foreign key

これにアクセスする方法は、必要なイベントを取得してから、関連する日付制限を確認することです。

日付制限のみを参照する必要がない場合、このテーブルに主キー列を追加することは良い習慣ですか、それとも推奨されますか?

4

5 に答える 5

5

常に主キーが必要です。主キーがあると、SQL Server はより効率的な方法でデータを物理的に格納できます。また、主キーを使用すると、Entity Framework で行を一意に簡単に識別できます。

列全体で自然キーを探します。単一の EventId がこのテーブルに 1 行しかない場合は、EventId に主キーを作成します。

自然キーがない場合は、テーブルに代理キー列を追加して ID にします。

于 2013-03-13T20:34:22.460 に答える
1

データベース内の行を一意に識別する方法を EF に伝える必要があります。各イベントがテーブルに 1 回しか表示されない場合は、EventId を主キーと外部キーの両方にすることができます。3 つの列すべてを複合主キーにすることもできます。例えば：

class DateRestriction {
  [Key, Column(Order=0)]
  public DateTime DateFrom {get;set;}

  [Key, Column(Order=1)]
  public DateTime DateTo {get;set;}

  [Key, Column(Order=2)]
  public int EventId {get;set;}
}
于 2013-03-13T20:33:41.957 に答える
0

データベース内のこのテーブルが別のテーブルから直接参照されている場合は、いいえ。あなたの構造の残りの部分がなければ、私は完全にはわかりません。したがって、一般的な経験則と例を示します。

顧客テーブル:

  • ID
  • 名前
  • 最後

しかし、個人にリンクすることなく、個々のアドレスを照会することはありません。これで、Addressという 2 番目のテーブルができました。

  • 顧客ID
  • 街
  • 街
  • ジップ
  • 州

したがって、この 1 つのCustomerは常に関連付けられたアドレスを持つため、a を定義しても問題ありませんForeign Key。ここで、Customerが複数のAddressPrimary Keyを持つことが許可されている場合、はい、構造が自立するように が必要になります。

その特定のデータが常に別のテーブルに関連付けられている場合は、Foreign Key. 明らかに、実装とデータベースへのアクセスが影響を与える可能性があります。したがって、警戒する必要があります。次のようなさまざまなテクノロジーを利用している場合：

  • エンティティ フレームワーク
  • あど
  • 等

したがって、データベースとアプリケーションの両方の実装と設計に注意してください。

ただし、データベースを最適化できるようPrimary Keyに定義する必要があります。いつもIndexesのように。 Primary KeyIndexed

インデックス付きの代理キーで十分です。

質問を誤解した場合は申し訳ありませんが、うまくいけば、これが正しい場所にあることを願っています.

于 2013-03-13T20:34:17.767 に答える