主キーは通常正の整数です。データモデルクラスの主キーとしてintの代わりにuintを使用することをお勧めしますか？
intの代わりにuintをデータモデルクラスの主キーとして使用することをお勧めしますか？
例：
public class Customer
{
public uint CustomerId {get;set;}
//others are omitted for the sake of simplicity.
}
対応するSQLデータ型は符号付きの数値なので、驚きを避けるためにintを使用します。
対応するSQLデータ型をuintに変更できますか？ – xport
@リサイクルビン：私が気づいているわけではありませんが、私はなぜあなたがしたいと思うか分かりません。 20億を超える数字が本当に必要な場合は、bigintに切り替えたり、UniqueIdentifierのようなものを検討したりすることができます。 –
私はint型の原因は、より.NET Frameworkで使用するために最適化され、それは悪いアイデアだと思います。
int.MaxValueという顧客以上のものを扱うにはどうしますか？ – xport
@Recycle Bin：もし私が20億人以上の顧客を抱えていれば、署名されたintとunsigned intをキーに使用することの問題は、私の懸念事項のリストのどこにもありません。それがあれば、いつもlong/bigintがあります。 –
私が強くお勧めする1つの方法は、どこでも短いキーを使用することです。私の良い（と非常にスマートな）友人は、特定のパフォーマンスクリティカルなテーブルが2^16レコードに近づくことがないという非常に現実的な前提の下で、かつてこれを行った。後でデータベースリファクタリングの2つ、ビジネスの成長、問題のテーブルがその限界にぶつかっていました。データの量とキーの伝播のために、その1つの列をintに移行するには月に十数人の人が必要でした。 –
他の人がこの質問に遭遇する場合は、uintをキーに使用しないでください。私はちょうどEntity Framework 6.1.12でそれを試してみました。そして、コードは暗号を持たない "Entity does not have key"例外で失敗し続けました。
uintプロパティをintに変更した後でのみ、期待どおりに動作するようになりました。
それで、ええ、20億の範囲は未使用ですが、それは事態です。あなたが10億以上の記録を残してしまうかもしれないことに少しでも疑問があるなら、長い時間を過ごしてください。皮肉なことに、9,223,372,036,854,775,808の数字は未使用です。
9,223,372,036,854,775,807があなたには不十分であると思っていますか?-) – zerkms
@zerkms：考えてはいけません。それは私の想像以上です。 – xport
@Recycle Bin：違いはありません。 – zerkms