EF Code Firstは、すべての文字列にnvarchar（max）を使用します。これによりクエリのパフォーマンスが低下しますか？

Entity Framework Code Firstを使用していくつかのデータベースを作成しています。アプリは正常に動作しており、一般的にCode Firstでできることにはかなり満足しています。私は必然的にプログラマーであり、DBAは2番目です。私はデータベースで何をしたいのかをC＃でさらに説明するためにDataAttributesについて読んでいます。私の質問は、これらのnvarchar(max)文字列をテーブルに入れることでどのようなペナルティを食べるのかということです（下の例を参照）。

この特定のテーブルにはいくつかの列があります。C＃では、次のように定義されています。

    [Key]
    [DatabaseGeneratedAttribute(DatabaseGeneratedOption.Identity)]
    public int ID { get; set; }
    public string Name { get; set; }
    public string Message { get; set; }
    public string Source { get; set; }
    public DateTime Generated { get; set; }
    public DateTime Written { get; set; }

Name、Source、Generated、Writtenに基づいてクエリやソートを行う予定です。NameとSourceの長さは0〜50文字、場合によっては最大150になると予想しています。このテーブルはかなり小さい（<100k行）から始まりますが、時間の経過とともに大幅に増加する（> 1m行）明らかに、メッセージは小さくても大きくてもかまいませんし、おそらく問い合わせることはないでしょう。

私が知りたいことは、名前とソースの列がnvarchar(max)150文字を超えることは決してないと予想されるときに定義されているパフォーマンスのヒットがありますか？

より大きなnvarchar（max）データアイテム（8000バイト以上）はテキストストレージにあふれ、追加のI / Oが必要になります。小さいアイテムは行に格納されます。この動作を制御するオプションがあります-詳細については、MSDNの記事を参照してください。

インラインに格納されている場合、I / Oパフォーマンスの大きなオーバーヘッドはありません。データ型の処理で追加のCPUオーバーヘッドが発生する可能性がありますが、これは軽微です。

ただし、nvarchar（max）列が不要なデータベースの周囲に配置するのは、かなり貧弱な形式です。これは、いくつか持っているパフォーマンスのオーバーヘッドが広いVARCHAR列50または100文字、例えば可能性の高い1（例えば）の説明またはフリーテキストフィールドになることです、10- -そして多くの場合、データサイズがデータテーブルを理解する上で非常に有用です20文字はコードである可能性があります。このような仮定を通じて、データベースから多くの場合に推論する必要のある意味を驚くでしょう。

サポートが不十分な、または文書化されたレガシーシステムではない場合と同様に、データウェアハウジングでの作業は、理解しやすいデータベーススキーマを持つことは非常に有益です。データベースをアプリケーションのレガシーと考えている場合は、データベースを継承しようとしている人々に優しくしてください。

これはあなたの特定の質問に答えるものではありませんが、そもそも質問をする必要がなくなるかもしれません：C＃モデルクラスの文字列変数に長さを設定することは可能です。ではなく、固定長のnvarchar型（などnvarchar(50)）を使用しnvarchar(max)ます。

たとえば、次の代わりに：

public string Name { get; set; }

次を使用できます。

[StringLength(50)]
public string Name { get; set; }

必要に応じて、次のようにタイプをのvarchar代わりに強制することもできnvarcharます。

[Column(TypeName = "VARCHAR")]
[StringLength(50)]
public string Name { get; set; }

ソース：https : //stackoverflow.com/questions/7341783/entity-framework-data-annotations-set-stringlength-varchar/7341920

最大の懸念事項の索引付け。BOLから：

ラージ・オブジェクト（LOB）データ型である列はntext、text、 varchar(max)、nvarchar(max)、varbinary(max)、xml、またはimageインデックスのキー列として指定することができません。

適切にインデックスを作成できない場合、クエリが遅くなります。また、データの整合性の観点から、nvarchar(max)制限を指定するよりも多くの不正なデータをフィールドに入れることができます。

はい、マッピングのデフォルトのEFの行動stringにはnvarchar(max)良くありません。EF 6では、独自のカスタムコンベンションを追加して、この動作を独自のデフォルトマッピングでオーバーライドできます。

protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
    modelBuilder.Properties<string>()
        .Configure(s => s.HasMaxLength(200).HasColumnType("varchar") );

    base.OnModelCreating(modelBuilder);
}

OnModelCreating上記のようにオーバーライドすると、すべての文字列のデフォルトのマッピングがに変更されますvarchar(200)。