c# - UserID 在 ASP.NET Identity 中是字符串类型的可能缺点

Question

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

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

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，但我想 Microsoft 将其设计为 String 是有充分理由的。

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

看起来默认类型不能满足我们的需求，对吧？

Answer 1

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

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

现在这个默认值对某些用户不利，我改写你的例子:

如果我们有一个用户事件表，其中 string users 表的外键在行大小中占主导地位，那么我们可能会考虑为 users 表选择一个较小的主键。

我认为，与希望迁移到 Identity 的人相比，这是一个不太常见(但更高级)的场景，我同意那些做出该决定的人。

也就是说，我个人改为int或 guid PK 取决于项目，因为这也会减少包含 UserId 的所有索引的大小