如何修改代码第一种方法中现有的IdentityUser列大小

我使用代码优先的方法。总是我们不希望在我们的表中添加NVarchar（max）。但是当我们在AspNetUser表中使用身份帐户管理时，默认列中包含NVarchar（max），如下图所示。我的团队认为varchar（Max）会降低性能。如何修改代码第一种方法中现有的IdentityUser列大小

在数据库

在代码

现在我的问题是

1）是需要有VARCHAR（最大值）的那c olumn？

2）我们可以减少该列的大小吗？

3）如果是，如何减少该列大小？

4）当具有Varchar（Max）时真的会出现这样的性能问题吗？（我知道为什么我们不应该使用它，但引导我，是这样一个大问题）

许多文章只解释如何包括在该表中的新列，但不修改现有的列。请帮助我。

对不起，如果你不明白我的问题，请问我。

来源

2016-04-27 ManiMaranVasan

你可以用流利的配置设置长度：

public class ApplicationUser : IdentityUser 
{ 
    ... 

    public class Mapping : EntityTypeConfiguration<ApplicationUser> 
    { 
     Property(m => m.PasswordHash).HasMaxLength(50) 
     Property(m => m.SecurityStamp).HasMaxLength(50) 
     Property(m => m.PhoneNumber).HasMaxLength(50) 
    } 
}

然后，在你的背景：

public class ApplicationDbContext : IdentityDbContext<ApplicationUser> 
{ 
    ... 

    protected override void OnModelCreating(DbModelBuilder modelBuilder) 
    { 
     modelBuilder.Configurations.Add(new ApplicationUser.Mapping()); 
    } 
}

对于确切的列长度来使用，你可能需要做一些测试。我不认为PasswordHash或SecurityStamp值本身具有固定长度，所以您需要发现一些上限。 PhoneNumber是相当直接的，但如果你与国际用户打交道，请记住它在美国只有10位数。其他国家使用各种不同的电话号码格式和长度。

尽管如此，这主要是浪费时间，精力和精力。尽管使用MAX与定义的长度相比会产生理论性的性能影响，但影响可以忽略不计，并且在实践中不会引起注意甚至无法衡量。使用MAX唯一真正的缺点是您无法在该列上应用索引。但是，如果您打算按该列进行查询，则这一点很重要，这对于您关心的三列来说是极不可能的。身份始终通过ID，用户名或电子邮件查找用户，而不是按PasswordHash或SecurityStamp查找用户，并且您可能多久查看一次用户的电话号码？

总而言之，你真正在这里做的是为你自己引入潜在的维护问题。您需要从此保持关注这些列，并且确保不仅仅是您已经选择了一个好的长度，而且未来版本的Identity不会做一些影响长度的修改。

来源

2016-04-27 17:16:01

关于引入额外维护的好处是没有性能增益。 – trailmax

如何修改代码第一种方法中现有的IdentityUser列大小

回答

相关问题