既定では、EF 4.2 codefirst は、文字列プロパティの背後にあるデータベース列を nvarchar(max) に設定します。
個別に (プロパティごとに)[MaxLength(512)]
属性を指定することで、この規則をオーバーライドできます。
これを行う構成をグローバルに適用する方法はありますか? モデルビルダーの構成 API はエンティティごとのオーバーライドのみを許可し、モデルビルダーの規約 API は削除のみを許可しているようです。この質問を参照してください。
既定では、EF 4.2 codefirst は、文字列プロパティの背後にあるデータベース列を nvarchar(max) に設定します。
個別に (プロパティごとに)[MaxLength(512)]
属性を指定することで、この規則をオーバーライドできます。
これを行う構成をグローバルに適用する方法はありますか? モデルビルダーの構成 API はエンティティごとのオーバーライドのみを許可し、モデルビルダーの規約 API は削除のみを許可しているようです。この質問を参照してください。
いいえ、利用可能なグローバル構成はありません。カスタム規則は、CTP フェーズで EF Code First から削除されました。
私はあなたがそれを行うことができると思います。モデル テーブルのプロパティのすぐ上に、StringLength 属性を追加します。フォローするのと同じように。(System.ComponentModel.DataAnnotations を使用して含める必要があることに注意してください;)
[StringLength(160)]
public string Title { get; set; }
アップデート
まず、nvarchar(MAX) 列にインデックスを作成することはできません。フルテキスト インデックスを使用できますが、列にインデックスを作成してクエリのパフォーマンスを向上させることはできません。
ストレージの見通しから、N < 4000 の場合、nvarchar(max) と nvarchar(N) の間に違いはありません。収まらない場合、データは行または行オーバーフロー ページに格納されます。nvarchar(max) を使用して 4000 文字 (8000 バイト) を超えるデータを格納する場合、SQL Server は、古い TEXT データ型と同様に、別の方法でデータを格納し、LOB ページに格納します。
パフォーマンスに関して - 繰り返しますが、N<4000 および (最大) の場合 - 違いはありません。まあ、技術的には、行サイズの見積もりに影響を与え、いくつかの問題を引き起こす可能性があります-詳細については、ここで読むことができます: 利用可能な幅の列の最適な方法
システムのパフォーマンスに影響を与える可能性があるのは、行サイズです。SCANテーブルのクエリがある場合、行サイズが大きいと、テーブルごとのデータページが増えます-> io操作が増えます->パフォーマンスが低下します。この場合は、垂直分割を行い、nvarchar フィールドを別のテーブルに移動してみてください。