用户 ID 在 ASP.NET 标识中属于字符串类型的可能缺点

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

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

当您设计类似标识的库时，您希望最简单和最常见的用例尽可能易于设置。 一个常见的用例是将现有用户群迁移到标识。现有用户可能将int、long、guid或string作为其主键。因此，最可靠的默认值是为主键选择string以支持所有内容。

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

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

我认为与想要迁移到 Identity 的人相比，这是一种不太常见(且更高级(的情况，我同意做出该决定的人。

也就是说，我个人根据项目更改为int或guidPK，因为这也会减少所有包含UserId的索引的大小