ASP.NET Identity 中 UserID 为字符串类型的可能缺点

Question

一直在开发一个自动处理审计的应用程序。

我的许多 EF 模型都继承了 FullAudited class。

public class FullAudited<TPrimaryKey> : Entity<TPrimaryKey>, IFullAudited, ISoftDelete
{
    public DateTime CreationTime { get; set; }
    public string CreatorUserId { get; set; }
    public DateTime? ModificationTime { get; set; }
    public string ModifierUserId { get; set; }
    public DateTime? DeletionTime { get; set; }
    public string DeleterUserId { get; set; }
    public bool IsDeleted { get; set; }
}

看，我们有 CreatorUserId、ModifierUserId、DeleterUserId。

想象一下应用程序运行多年的情况，我们在数据库中有无数的记录 - 每个字段都包含 GUID 字符串，例如 5a7618ee-d279-4df9-9fe0-23f7df3053bd.

当然，我们可以轻松地从 String 切换到 long，但我想微软将其设计为 String.

是有充分理由的

因此，如果我们将 UserID 保留为 String - 这样的应用程序肯定需要更多的存储空间。

默认的类型好像不能满足我们的需求吧？

Answer 1

我不知道微软的原因，我也没有看到这个选择背后的正式推理，但我们可以做出有根据的猜测。

当您设计像 identity 这样的库时，您希望最简单和最常见的用例尽可能易于设置。一个常见的用例是将现有用户群迁移到身份。您的现有用户可能将 int、long、guid 或 string 作为他们的主键。因此，最稳健的默认设置是选择 string 作为主键以支持所有内容。

现在这个默认值对一些用户不好，我改写你的例子：

如果我们有 table 的用户活动，其中 string 用户的外键 table 在行大小中占主导地位，那么我们可能会考虑选择一个较小的主键用户 table.

我认为这是一个比想要迁移到 Identity 的人更不常见（但更高级）的场景，我同意那些做出该决定的人。

也就是说，我个人根据项目更改为 int 或 guid PK，因为这也会减少包含 UserId

的所有索引的大小

ASP.NET Identity 中 UserID 为字符串类型的可能缺点

possible drawback of UserID being of string type in ASP.NET Identity

c#

asp.net

asp.net-identity