0

多くのデータを保持すると予想されるテーブルを持つ Entity Framework モデルがあります。それよりも大きくなると予想されるため、int 主キーを使用することに懸念があります。この問題を回避するために Int64 を使用することを検討しています。

これが本当のキッカーです-問題のテーブルでタイプごとの継承を使用しています。したがって、Int64 を使用すると、int64 の主キーを使用する必要がある他のいくつかのテーブル (実際にはさらに追加するため、任意の数のテーブル) が存在しますが、それらが int の境界を超えて大きくなる可能性はありますかなりスリムです。非効率的なソリューションのようです。考え？

int ID とサブタイプ識別子 (おそらく char) で構成される複合キーを使用することを考えていました。このアプローチのパフォーマンスへの影響について疑問に思っています。単純な連想エンティティでない限り、私は常に代理キーを好んでいました。これらのいずれかよりも優れたアプローチはありますか? これらのうち、好ましいルートはどれですか?

アップデート：

私が検討している複合キーは自然な複合キーではないことを明確にしたいと思います。ID とサブタイプ識別子のみが含まれます。int 主キーのサイズ制限を回避する方法として使用することに興味があります。私の主な懸念事項は次のとおりです。

1) Int64 主キーを使用すると、パフォーマンス上の問題はありますか? 特に、親テーブルにのみ必要ですが、子テーブルでも使用する必要がある型継承ごとのテーブルでは。

2) 複合キー (非自然) を使用して int 主キーよりも広い範囲を実現すると、Int64 キーを使用して同じことを行うよりもパフォーマンス上の利点がありますか?

4

1 に答える 1

1

この SO の質問/回答を確認してください。基本的に、両方を使用しないのはなぜですか？結合と外部キーには整数代理キーを使用しますが、データの一貫性を確保し、重複する行を挿入するリスクを最小限に抑えるために、(正しい自然キーが複合キーである場合)意味のある複合自然キーがあることを確認してください...

BigintId  firstName LastName   Phone        Gender   Birthdate
  1         Bob      Smith    111 234-5678    M     1 jan 1978
  2         Bob      Smith    111 234-5678    M     1 jan 1978
  3         Bob      Smith    111 234-5678    M     1 jan 1978
  4         Bob      Smith    111 234-5678    M     1 jan 1978

id が異なるという理由だけで、これらは本当に異なるエンティティですか? 盲目的にdifferentを再定義して、それが別の Key を持つことを単に意味する場合にのみ...

于 2013-09-05T08:16:48.067 に答える