私はEntity Frameworkをコードファーストで使用しています。私は100行を超えないテーブルを持っており、プライマリキーとしてデータ型byte（SQL Serverではtinyint）を使用したいと考えています。バイトを主キーのデータ型として使用する
これは私がこれまで持っているものです：Entity Frameworkのは、データベースを作成するときに
[Key]
public byte Id { get; set; }
問題があり、それが挿入時に自動インクリメントに行を可能にするアイデンティティ仕様プロパティを設定されていません。
データ型をInt16（SQL Serverではsmallint）に変更すると、すべてが完全に機能します。
エンティティフレームワークに自動インクリメントプロパティを設定するよう指示する方法、またはEntity Frameworkでコードファーストでプライマリキーとして使用しないバイトを使用する方法はありますか？
byteタイプは、キーとID列としてサポートされています。同一性の主キーとしてbyteをマークするのはデフォルトではありません。しかし、あなたは、このデフォルトを上書きすることができます（？そしておそらくより多くの種類）を明示的Identityオプションを設定
[Key, DatabaseGenerated(DatabaseGeneratedOption.Identity)]
public byte Id { get; set; }
は、longとshortintのために必要はありませんが、SQLでbyte（= tinyintのためでありますサーバ）。私はテストでそれを理解しましたが、どこにでも公式に文書化されているのを見つけられませんでした。
完璧！まさに私が探していたもの！ありがとうございました！ – user962926
非識別プライマリキーである 'short'プロパティの場合、この属性を' DatabaseGeneratedOption.None'値とともに使用しなければなりませんでした。ありがとう！ – STW
追加のマイグレーションで新しい属性をタックするだけでは機能しませんでした。 IDENTITY（1,1）は追加されませんでした。最終的に追加する前に、マイグレーションとテーブルを削除する必要がありました。私はEF 6.1.3を使用しています。 –
なぜこのようにデータベースを制限しますか？ほんの数行であれば、追加されたスペースは傷ついていません。 – delnan
@delnan、そうだね、なぜそれをvarchar（100）** ';-)' **にしないの？特にPKの場合には、常に最も制限の厳しい正しいデータ型を選択する必要があります。 5,000万行のテーブルでこのPKをFKとして使用し、インデックスを追加すると違いがあります。列のサイズは、ディスク・スペース以上に影響します。キャッシュ・メモリーと、些細なデータ型選択エラーでどれくらい浪費するかについて考えるだけです。また、アプリケーションがフリークアウトしてアウト値または範囲値を挿入しようとすると、失敗します。 –