存档表是否应该有自己的代理标识密钥？

Question

归档表是否应该有自己的代理标识id/key？对于客户销售表示例：

• 我们有原始表，然后是带有代理存档id的附加存档表。
• 主聚集索引的规则是：
  • 不断增加
  • 窄
  • 独一无二
  • 静态

参考资料：有效聚类指标 (红门枢纽)

在我为之工作的上一家公司，有一种想法是，如果我们意外地错过了一天或一段时间的导入，例如5月3日的导入数据，意外地跳过了5月4日(与系统有关的问题)和导入的5月5日，如果没有新的归档id，我们将不得不在页面之间重新插入数据，从而导致碎片化和较慢的插入。

有了归档id，我们就可以以一种不断增加的方式添加。

只是询问添加档案栏是否是一种标准的行业惯例。

原始表：

create table dbo.CustomerSalesId
(
    CustomerSalesId bigint primary key identity(1,1),
    CustomerId bigint not null,
    PurchaseDate datetime not null,
    Amount decimal (10,2) not null,
    .........
}

存档表：

create table dbo.ArchiveCustomerSalesId
(
    ArchiveCustomerSalesId bigint primary key identity(1,1),
    CustomerSalesId bigint,
    CustomerId bigint not null,
    PurchaseDate datetime not null,
    Amount decimal (10,2) not null,
    .........
}
create unique index ux_CustomerSalesId on ArchiveCustomerSalesId(CustomerSalesId)

Answer 1

碎裂并不像你想象的那么糟糕。页面完整(内部碎片)比页面的物理顺序(外部碎片)重要得多。

当从磁盘读取页面时，按顺序插入行可能会影响扫描的性能。从内存中读取页面时，页的顺序是否正确并不重要。另外，您可能没有使用物理服务器，您的磁盘可能是位于SAN上的LUN，因此页面毗连的优势可以忽略不计。

关于内部和外部碎片的很好的可视化描述可以在这里找到：http://www.sqlservercentral.com/blogs/practicalsqldba/2012/04/05/sql-server-index-fragmentation-understanding-fragmentation/

在布伦特·奥扎尔的博客：https://www.brentozar.com/archive/2012/08/sql-server-index-fragmentation/上可以找到一篇关于为什么碎片不是你认为的那样的伟大文章。

也就是说，使用额外的代理密钥来避免碎片并不是一个好主意。一个好的聚集索引首先是您使用最多的键来定位数据，这样您就不必执行额外的查找。如果在归档数据时更改群集键，则要定位行，必须在前一个群集键的列(S)上使用唯一的非聚集索引。非聚类索引是需要额外空间的数据的副本，还需要查找以提取不属于索引的列。

结束:不，您不需要额外的"archiveId“代理密钥。

Answer 2

最近，我为我目前工作的系统进行了这个练习。我选择保留当前的代理ID。

这主要是为了保留历史参考资料。我们有使用ID作为外部引用的各种辅助进程。这可能不是最好的实践，但这就是它的方式。内部日志也捕获ID。出于这些原因，我希望在归档表的值中保留活动表的ID。增加另一个达到同样目的的专栏似乎是多余的。

至于碎片化，这不是一个问题。这些行将用于两种情况--点查找(列Y的X行值是多少？)或者广泛的总量(我们在一月份有多少个Zs？)无论是哪种方式，稍微分散一点都不会对我们造成伤害。

当我们的数量显著增长，我们的分析变得更加复杂时，我可能需要重新审视这个问题。我可能会使用分区和联机重建( Server 2014+)。