ASP.NET Identity - изменить код сгенерированной длины поля базы данных для производительности

Question

Я использую идентификатор ASP.NET MVC 5. Я разрешил EF-код сначала создавать таблицы базы данных для меня. PasswordHash, SecurityStamp и PhoneNumber - все nvarchar (MAX) - но когда я смотрю их контент, они намного короче.

Для моего основного DAL я использую Dapper - хотя я позволяю EF обрабатывать Identity.

По причинам производительности базы данных я могу сократить эти поля MAX, гарантируя, что Identity все еще функционирует правильно - и если да, то какой длины?

(Я предполагаю, что могу использовать все, что мне нравится, с помощью PhoneNumber, поскольку я контролирую содержимое этого поля, но я не уверен в отношении других 2).

Я не могу найти что-либо упоминающее об этом в Интернете.

Answer 1

Я не совсем уверен, насколько это поможет вам с производительностью, но вы можете настроить свойства идентификаторов с помощью текучего API:

public class YourContext : IdentityDbContext 
{ 
    protected override void OnModelCreating(DbModelBuilder modelBuilder) 
    { 
     //Make you you do this BEFORE the code below 
     base.OnModelCreating(modelBuilder); 

     //Assuming your user class is called "User" here: 
     modelBuilder.Entity<User>() 
      .Property(e => e.PasswordHash).HasMaxLength(100); 

    } 
} 

Имейте в виду, хотя, если вы сделаете эти поля несовместимы с значения, которые Framework Identity хочет вставить, тогда вы столкнетесь с проблемами. Поэтому я бы рекомендовал довольно большое значение для максимальной длины.

Answer 2

Разница в SQL Server (я предполагаю, что это то, что вы используете) производительность при условии, что nvarchar (x) vs nvarchar (Max) - это когда вы выполняете поиск в этих полях. То есть select * from users where phoneNumber='123456789'.

Но поля, которые вы упоминаете, не подлежат обложению where в любом месте стандартного шаблона идентификации. Даже не SecurityStamp и определенно не на PasswordHash. Пользователи ищут по электронной почте, имени пользователя, идентификатору. И они для вас уже ограничены - 256 символов (see source, прокрутите до OnModelCreating). С индексом, нанесенным на столбец UserName.

Так что независимо от того, что вы говорите, вы не существуете.

Если вы делаете много поисков по электронной почте, вы можете применить индекс на столбец Email - это столько, сколько вы можете повысить производительность. То же самое касается номера телефона - если вы просматриваете пользователей по телефонным номерам, имеет смысл сделать этот столбец ограниченной длины и применить индекс.