Dal*_*Dal 13 guid auto-increment sql-server-2008
我最近开始了一项新工作,并注意到所有SQL表都使用GUID数据类型作为主键.
在我以前的工作中,我们使用整数(自动增量)作为主键,在我看来,它更容易使用.
例如,假设你有两个相关的表; Product和ProductType - 我可以轻松地交叉检查特定行的两个表的'ProductTypeID'列,以快速映射我脑中的数据,因为它易于存储数字(2,4,45等),而不是(E75B92A3- 3299-4407-A913-C5CA196B3CAB).
额外的挫折感来自于我想了解表格是如何相关的,遗憾的是没有数据库图表:(
很多人说GUID是更好的,因为您可以在C#代码中定义唯一标识符,例如使用NewID()而不需要SQL SERVER来执行此操作 - 这也允许您临时知道ID将是什么....但我已经看到有可能仍然检索'下一个自动递增的整数'.
DBA承包商报告说,如果我们使用Integer类型而不是GUIDS,我们的查询可以快30%...
为什么GUID数据类型存在,它真正提供了哪些优势？...即使是某些专业人士的选择,必须有一些很好的理由来解释为什么它的实现？
Ode*_*ded 17
在某些情况下,GUID作为标识字段很好:
GUID生成为全局唯一,这就是它们适合此类场景的原因.
mar*_*c_s 14
与大多数人似乎在宣讲的内容相反,我认为GUID更像是一场瘟疫,而不是一种祝福.原因如下:
GUID似乎是您主键的自然选择 - 如果您真的必须,您可能会争辩将其用于表的PRIMARY KEY.我强烈建议不要使用GUID列作为群集密钥,默认情况下SQL Server会执行此操作,除非您明确告知不要这样做.
你真的需要分开两个问题:
该主键是一个逻辑结构-候选键唯一和可靠地识别你的表中每一行的一个.这可以是任何东西,真的 - 一个INT,一个GUID,一个字符串 - 选择对你的场景最有意义的东西.
在聚集键(列或定义表上的"聚集索引"列) -这是一个物理存储相关的事情,在这里,一个小的,稳定的,不断增长的数据类型是您最好的挑选- INT或BIGINT作为您的默认选项.
默认情况下,SQL Server表上的主键也用作群集键 - 但这不一定是这样!我个人看到将以前基于GUID的主/群集密钥分解为两个单独的密钥 - GUID上的主(逻辑)密钥和单独的INT IDENTITY上的群集(排序)密钥(1, 1)专栏.
正如Kimberly Tripp--索引女王 - 和其他人已多次声明 - GUID因为聚类键不是最佳的,因为由于其随机性,它将导致大量页面和索引碎片以及通常不良的性能.
是的,我知道 - newsequentialid()在SQL Server 2005及更高版本中 - 但即使这样也不是真正的,完全顺序的,因此也会遇到与GUID相同的问题 - 只是不那么突出.另外,您只能将它用作表中列的默认值 - 您无法在T-SQL代码中获得新的顺序GUID(如触发器或其他东西) - 另一个主要缺点.
然后还有另一个需要考虑的问题:表格上的聚类键也会添加到表格中每个非聚集索引的每个条目上 - 因此,您确实希望确保它尽可能小.通常,对于绝大多数表来说,具有2亿行的INT应该足够了 - 并且与作为群集密钥的GUID相比,您可以在磁盘和服务器内存中节省数百兆字节的存储空间.
快速计算 - 使用INT与GUID作为主要和群集密钥:
总计:25 MB对106 MB - 这只是在一张桌子上!
还有一些值得思考的东西 - 金伯利·特里普的优秀作品 - 阅读,再读一遍,消化它!这是SQL Server索引福音,真的.
渣
INT
优势:
在连接,索引和条件中使用时,数值(特别是整数)更适合性能.如果显示应用程序用户,则数字值更易于理解.
缺点:
如果你的表很大,它很可能会耗尽它,并且在一些数值之后将没有额外的标识可供使用.
GUID
优势:
整个服务器都很独特.
缺点:
在连接,索引和条件中使用时,字符串值不如性能的整数值最佳.需要比INT更多的存储空间.
归功于:http://blog.sqlauthority.com/2010/04/28/sql-server-guid-vs-int-your-opinion/