我正在使用 SqlServer 和 Linq to Sql 开始新项目。
哪种数据类型更适合表中的代理键：identity 或 uniqueidentifier？
据我了解，identity 是在插入时自动生成的，而uniqueidentifier 应该在代码（GUID）中生成。
是否存在显着的性能差异？
例如identity 值必须在插入后读取，因此插入后会有额外的数据库行程。
编辑：
我在另一个问题中找到了非常详细的答案：Tables with no primary keys。阅读选定的答案。
编辑 2：
关于代理键的答案：我更喜欢代理键而不是自然键。该决定已完成，因此请不要建议重新考虑数据库设计。另外，请不要讨论自然键和代理键的优缺点。
【问题讨论】：
标签： sql-server linq linq-to-sql
我同意这里的评论，即您应该独立于数据访问方法来设计数据库结构。无论是 LINQ2SQL 还是 ADO.NET 或 NHibernate，无论您的 PK 是自动增量身份还是 GUID，您都将获得相同的好处/问题。
实际上，我只能想到一个目的，即使用 GUID 而不是 INT 作为 PK - 在具有多个数据库的高度分布式应用程序中，数据需要与主服务器同步等。即使这样，您也可以使用不同增量的 IDENTITY ，例如IDENTITY(1,2) 用于一个数据库服务器，IDENTITY (2, 2) 用于下一个数据库服务器等[当然仅适用于固定数量的数据库服务器。]
GUID 的主要“问题”是它占用更多空间（16 字节与 4/8 相比），不仅作为 PK，而且作为该表中任何索引的一部分，因为每个索引都隐式存储 PK 值.比较 16 字节也会更慢（多少？你应该测量它，这取决于）
此外，由于 GUID 是随机的，因此在向表中插入行时（尽管我相信 SQL Server 2005 或 2008 中有一个新函数可以生成连续的 GUID），您可能会得到很多页面拆分。在具有大量插入的环境中，仅此一项就可能非常昂贵。
【讨论】：
任何一个都可以。这取决于您的设计。当您需要在客户端创建 ID 时，UNIQUEIDENTIFIER 将起作用，当您构建需要在客户端上添加/删除/修改的对象列表时，这有时会很好，然后再发送到数据库。如果您必须合并在不同系统上创建的数据，那也更好。
INT 更小，因此它们可能会更快，并且当您使用数据调试某些内容时，它们更容易使用，因为它们更容易讨论。
简而言之，这里没有“最佳”答案。这是一个设计决定。
【讨论】：
我认为根据您使用 LINQ-to-SQL 的事实来选择表的主键不是一个好主意。在我看来，将主键用于其预期目的会更好 - 通过唯一标识特定行来确保数据完整性。整数或 GUID PK 不能保护您免受表中重复行的影响（当然，除了自动生成的列）。话又说回来，关于自动生成密钥的优缺点引起了激烈的争论:)
【讨论】：
我根据预期的表大小使用标识和 int 或 bigint。我希望 LINQ 执行一个结合插入和键读取的单一查询。
【讨论】：
uniqueidentifier也可以自动插入，通过将数据库中的默认值设置为NEWID()。
【讨论】：
好的，我刚刚写了一个blog about this。为了他人的利益，我在下面转发。
基本要点似乎是 ado.net 博客上的 cmets，其中指出 Entity Framework 是 Visual Studio 2010 和 Dot Net 4 的唯一主要开发人员时间。
我们已经知道了
我的回答是——呃。我们都知道这一点。微软在 PDC 2007 上公开表示，LINQ to SQL 是 SQL Server 的短期版本，因为 SQL Server 没有其他 LINQ 故事。它仅适用于 SQL Server。您不能编写 LINQ to SQL 提供程序 - 它没有模型。这是一种一次性技术，不可扩展。
实体框架 = 提供者
实体框架是 Microsoft 构建 LINQ 提供程序的唯一方法。实体框架被证明是相当有争议的，但我认为这部分是因为 LINQ to SQL 今天有更好的程序员体验。 Entity Framework 将赶上并超越 LINQ to SQL，因为它是 Microsoft 未来的 ORM/Mapping 工具。
我认为 Microsoft 在 Entity Framework 方面与我们、IBM、Oracle 等第三方供应商进行了巨额投资。如果他们希望第三方开发人员和数据库支持 LINQ，他们必须有一个可以写入的模型。实体框架就是答案。
去年，当他们使用 VS 2008 而不是 EF 发布 LINQ to SQL 时，我看到了这一点。他们永远不应该发布具有如此多重叠的东西的封闭实现。我知道他们想要一个关系数据库的故事，但我认为他们讲错了。现在有很多非常困惑的开发人员来向我们询问我们的 LINQ to SQL 提供程序。没有，因为你不会写。
【讨论】：