Guid 为空，首先使用 newsequentialid() 和 EF 数据库答案

【问题标题】：Guid is empty with newsequentialid() and EF database firstGuid 为空，首先使用 newsequentialid() 和 EF 数据库
【发布时间】：2015-04-13 15:05:05
【问题描述】：

我首先在使用 EF 4.1 和数据库的网站上工作。我也在使用 aspnet 表，尤其是 aspnet_Users，它使用 Guid 作为主键。因此，我的自定义 User 表也有一个 Guid 作为主键，它是 aspnet_Users id 的外键。

最近，我读到除非使用 newsequentialid()，否则使用 Guid 作为主键是个坏主意。

使用 Sql Server Management Studio，我已将所有主键的默认值更新为 newsequentialid()，并在我的 edmx 设计器中将 StoreGeneratedPattern 设置为 Identity。

但是，每当我尝试添加一个对象（例如 Item 具有 Guid 主键）时，它的 id 在数据库中保持为空（全为 0）。

public void CreateItem()
{
    using (var uof = new UnitOfWork())
    {
        Item item = new Item();
        itemRepo.Add(item);
        uof.Commit();
    }
}

还有添加方法：

public class RepositoryBase<TObject> where TObject : IEntity
{
    protected CavalenaEntities entities
    {
        get { return UnitOfWork.Current.Context; }
    }

    public void Add(TObject entity)
    {
        entities.Entry(entity).State = System.Data.EntityState.Added;
    }
}

我是不是忘记了什么？虽然我为我的数据库的主键设置了默认值，但它们在 edmx 设计器中的Default Value 属性仍然是None。正常吗？

另一种解决方案是使用 int 作为主键而不是 Guid，但是我怎样才能在我的自定义用户表和使用 Guid 的aspnet_Users 之间建立链接？

非常感谢！

【问题讨论】：

标签： c# asp.net entity-framework ef-database-first newsequentialid

【解决方案1】：

在模型设计器中获取主键的属性。找到 StoreGeneratedPattern 并将其从 None 更改为 Identity。保存所有内容，现在主键将正确生成。

【讨论】：

【解决方案2】：

除非您需要序列标识符，否则使用NEWID() 绝对没问题。但是你可能不需要Guid/uniqueidentifier，你可以使用int或bigint和身份或SQL序列对象。

【讨论】：

我并不真正需要序列标识符，但根据我阅读的帖子，newid() 将插入表中的任何位置，而newsequentialid() 将始终添加到表的末尾，所以刀片的性能得到改善。我可以使用int，但是如何在aspnet_Users' id（即 Guid）和我的自定义用户表（如果我将其主键从 Guid 更改为 int）之间维护一个外键？
这取决于您的 CLUSTER INDEX 是什么。该表不是简单的列表。物理存储是用 b-tree 制作的。事实上，在表的不同部分插入记录可以使 INSERT 更快。一切都取决于您的 CLUSTER INDEX 及其填充因子。但是，我认为您不会有这么多新用户需要在 INSERT 中进行优化。真的很快。
簇索引是主键（我已经读过这是默认行为，我没有改变它），也就是说Guid。我不得不承认我对集群索引不太熟悉，但你实际上是对的，我真的不需要优化 INSERT。但是，我需要出色的搜索性能。 newid() 不会降低它吗？
您确定插入会被瓶颈吗？因为，您很有可能正在尝试对部分代码进行微优化，这将很快。您的应用程序代码很有可能会比插入新记录慢得多。
其实我不是，这只是我读到的 (stackoverflow.com/questions/1587185/…)，我很新，正在学习最佳实践和优化性能的方法。因此，我只是阅读了讨论这个问题的帖子，说newsequentialid() 更适合处理碎片，但在我的情况下实际上可能完全没有必要。如果它只影响插入而不影响搜索，我想我可以保留newid()。