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。

想象一下应用程序运行了多年的情况，并且数据库中有无数的记录-这些字段中的每个字段都包含5a7618ee-d279-4df9-9fe0-23f7df3053bd之类的GUID字符串。

我们当然可以轻松地从String切换到long，但是我想Microsoft将其设计为String的理由很充分。

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

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

Answer 1

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

在设计类似身份的库时，您希望最简单和最常见的用例尽可能容易地设置。一种常见的用例是将现有的用户库迁移到身份。您现有的用户可能将int，long，guid或string作为其主键。因此，最可靠的默认设置是选择string作为主键以支持所有功能。

现在，此默认设置对某些用户不利，我重新举一个例子：

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

与要迁移到身份的人们相比，我认为这是一种不常见（更高级）的方案，并且我同意那些做出决定的人。

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

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

1 个答案: