如何在代码优先方法中修改现有的 IdentityUser 列大小

Question

我使用代码优先的方法。我们总是不喜欢在我们的表中添加 NVarchar(max)。但是当我们默认使用身份帐户管理时，AspNetUser 表中的列包含 NVarchar(max)，如下图所示。我的团队认为使用 varchar(Max) 会降低性能。

在数据库中

在代码中

现在我的问题是

1) 是否有必要在该列中使用 varchar(max)？

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

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

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

许多文章只解释了如何在该表中包含新列，而不是修改现有列。请帮助我。

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

Answer 1

您可以使用 fluent config 来设置长度：

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());
    }
}

对于要使用的确切列长度，您可能需要进行一些测试。我不认为PasswordHashorSecurityStamp值本身具有固定长度，因此您需要发现一些向上限制。PhoneNumber相当简单，但如果您与国际用户打交道，请记住它在美国只有 10 位数字。其他国家/地区使用各种不同的电话号码格式和长度。

尽管如此，这主要是在浪费时间、精力和精力。虽然使用MAX与定义的长度相比会产生理论上的性能影响，但这种影响可以忽略不计，并且在实践中不会明显或什至无法真正衡量。使用的唯一真正缺点MAX是您不能在该列上应用索引。但是，这仅在您打算按该列查询时才重要，这对于您关注的三列来说是极不可能的。Identity 总是通过 id、用户名或电子邮件查找用户，从不通过PasswordHash或SecurityStamp，您多久会通过电话号码查找用户？

总而言之，您在这里真正要做的就是为自己引入潜在的维护问题。从今以后，您需要密切关注这些列，并确保您不仅选择了合适的开始长度，还要确保 Identity 的未来版本不会进行一些影响长度的修改。