uni*_*rio 1 sql guid data-warehouse
我爱我的GUID.但是,最近我一直在做一些研究,以了解IDENTITY对主键的实际利弊,我发现这篇文章很好地总结了它.
在作者的文章中:
- 对数据仓库非常有用;
作为使用IDENTITY优于GUID的优点之一.
我会理解,对于特别大的数据库,与数据仓库一样,大小确实很重要 - 但是看起来还有其他原因导致文章无法解释.所以我问:
为什么GUID对日期仓库来说不是一个好主意？
mar*_*c_s 14
GUID似乎是您主键的自然选择 - 如果您真的必须,您可能会争辩将其用于表的PRIMARY KEY.我强烈建议不要使用GUID列作为群集密钥,默认情况下SQL Server会执行此操作,除非您明确告知不要这样做.
你真的需要分开两个问题:
1)主键是一个逻辑结构 - 一个候选键,它唯一且可靠地标识表中的每一行.这可以是任何东西,真的 - 一个INT,一个GUID,一个字符串 - 选择对你的场景最有意义的东西.
2)聚类键(在表上定义"聚簇索引"的一列或多列) - 这是一个与物理存储相关的东西,这里,一个小的,稳定的,不断增加的数据类型是你最好的选择 - INT或BIGINT作为默认选项.
默认情况下,SQL Server表上的主键也用作群集键 - 但这不一定是这样!我个人看到,在将先前基于GUID的主/群集密钥分解为两个单独的密钥(GUID上的主(逻辑)密钥)和单独INT IDENTITY(1,1)列上的群集(排序)密钥时,可以获得巨大的性能提升.
正如Kimberly Tripp--索引女王 - 和其他人已多次声明 - GUID因为聚类键不是最优的,因为由于其随机性,它将导致大量的页面和索引碎片以及通常不良的性能.
是的,我知道 - newsequentialid()在SQL Server 2005及更高版本中 - 但即使这样也不是真正的,完全顺序的,因此也会遇到与之相同的问题GUID- 只是不那么突出.
然后还有另一个需要考虑的问题:表格上的聚类键也会添加到表格中每个非聚集索引的每个条目上 - 因此,您确实希望确保它尽可能小.通常,对于绝大多数表来说,具有2亿行的INT应该足够了 - 并且与作为群集密钥的GUID相比,您可以在磁盘和服务器内存中节省数百兆字节的存储空间.
快速计算 - 使用INT与GUID作为主要和群集密钥:
总计:25 MB对106 MB - 这只是在一张桌子上!
还有一些值得思考的东西 - 金伯利·特里普的优秀作品 - 阅读,再读一遍,消化它!这是SQL Server索引福音,真的.
渣
IDENTITY字段创建小而漂亮的索引.它们也是SEQUENTIAL,这意味着为它们创建的索引比常规GUID键索引碎片更少.使用SEQUENTIAL GUID可以让您更接近这种行为,但它仍有其缺点.GUID的一个优点是,即使跨数据库,它也往往是独一无二的,但它在大多数应用程序中都是性能和空间.
GUID Pros在每个表,每个数据库,每个服务器上都是唯一的允许轻松合并来自不同数据库的记录允许在多个服务器之间轻松分发数据库您可以在任何地方生成ID,而不必往返数据库大多数复制方案都需要GUID列
GUID缺点它比传统的4字节索引值大4倍; 如果你不小心调试麻烦(其中userid ='{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}'),这会产生严重的性能和存储影响.生成的GUID应该是部分顺序的以获得最佳性能(例如,newsequentialid()on SQL 2005)并支持使用聚簇索引
另外,要专门回答你的问题:我不认为你引用的文章说"GUID对于数据仓库来说是一个坏主意",就像它说"身份"字段在数据仓库中比自然键更有用.但是,如果您在数据仓库中存储大量记录,由于上面的索引投诉,使用IDENTITY列而不是GUID会获得更好的性能和更小的存储要求,我想这是主要的缺点.
| 归档时间： |
|
| 查看次数： |
3937 次 |
| 最近记录： |