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