EF Code First использует nvarchar (max) для всех строк. Повлияет ли это на производительность запросов?

У меня есть несколько баз данных, созданных с использованием Entity Framework Code First; приложения работают, и в целом я очень доволен тем, что мне позволяет Code First. Я программист первый, а второй администратор по необходимости. Я читаю о DataAttributes для дальнейшего описания в C #, что я хочу, чтобы база данных делала; и мой вопрос: какое наказание я буду есть, имея эти 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; }

Я ожидаю выполнить запрос и / или сортировку на основе имени, источника, сгенерированного и написанного. Я ожидаю, что Имя и Источник будут иметь длину 0-50 символов, иногда до 150. Я ожидаю, что эта таблица будет довольно маленькой (<100 тыс. Строк), но со временем значительно увеличится (> 1 млн. Строк). Очевидно, что сообщение может быть маленьким или большим, и, вероятно, не будет запрашиваться.

Что я хочу знать, есть ли снижение производительности для моих столбцов «Имя» и «Источник», которые определяются, nvarchar(max)когда я никогда не ожидаю, что они будут длиннее 150 символов?

Более крупные элементы данных nvarchar (max) (более 8000 байт или около того) будут перетекать в хранилище текста и потребовать дополнительного ввода-вывода. Меньшие предметы будут храниться в ряд. Есть варианты, которые управляют этим поведением - см. Эту статью MSDN для получения дополнительной информации.

При хранении в строке значительного снижения производительности ввода-вывода нет; при обработке типа данных могут возникнуть дополнительные затраты ресурсов процессора, но, скорее всего, они будут незначительными.

Однако оставлять столбцы nvarchar (max) в базе данных там, где они не нужны, довольно плохая форма. У него есть некоторые издержки производительности, и часто размеры данных весьма полезны для понимания таблицы данных - например, столбец varchar шириной 50 или 100 символов, вероятно, будет описанием или полем свободного текста, где (скажем) 10- 20 символов, вероятно, будут кодом. Вы будете удивлены, насколько много значат, что часто приходится делать из базы данных с помощью таких предположений.

Работа в хранилищах данных, зачастую не на плохо поддерживаемых или документированных устаревших системах, имеет простую для понимания схему базы данных. Если вы думаете о базе данных как о наследии приложения, постарайтесь быть милыми с людьми, которые собираются унаследовать ее от вас.

Хотя это не отвечает на ваш конкретный вопрос, это может помешать вам в первую очередь задавать вопрос: можно задать длину строковых переменных в классе модели C #, что заставит Entity Framework генерировать SQL, который использует фиксированный тип 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; }

Источник: /programming/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).