调度呼叫的表设计答案

【问题标题】：Table design for scheduling calls调度呼叫的表设计
【发布时间】：2019-09-09 15:31:24
【问题描述】：

假设您有一个呼叫中心需要在给定的一天内拨打 X 次电话。每个客户可以被要求支付 Y 数量的产品。企业希望在一天开始时将呼叫分配给接线员，然后能够每天评估这些呼叫的结果。

出于这些原因，我正在考虑将结构分为两部分，一张桌子用于客户，另一张用于产品。我遇到的问题是决定将主键放入主调度表中。由于每天都会有很多记录，所以我有一部分想把每天的数据按顺序写出来：

DateOfRecords   date      
Sequence        int    
OperatorID      int    
CustomerID      int

其余列…

以 DateOfRecords 和序列为主键。

我知道很多人建议建立一个整数作为主键，然后在其他列上建立索引。同样，我的问题是因为每天要保存的记录数量，因为这将是一个历史表。

有什么建议吗？

【问题讨论】：

您的问题到底是什么？ “有什么建议吗？” 范围太广，无法单独回答。仅仅是“DateofRecords 和 Sequence 是一个好的复合主键候选者吗？”
如果 sequence 是自动数字，为什么您需要 date 作为 PK 的一部分？
@Larnu 如果我的问题不够清楚，我很抱歉。基本上我是在寻求有关如何设计表格的建议。
@JuanCarlosOropeza 序列不是自动数字的。它将由应用程序创建。我们试图避免的是将一个主键作为单个数字列，然后在以后有数百万条记录时出现问题。
trying to avoid is having one primary key as a single numeric 不管你有几百万行，这都不是问题。这是推荐的方法。让应用处理序列可能会出现问题，因为您必须处理并发。

标签： sql-server database tsql database-design

【解决方案1】：

每个表只能有一个聚集键。在大多数情况下 - 但不一定 - 这将是主键。有几点需要考虑：

聚集键是物理表本身。它会自动包含所有列。
最好的聚集键是永远不会碎片化的键（例如序列）。最差的集群键是普通的 Guid。
如果有一个聚集键，它将作为其他索引的查找。如果聚集键不正确（例如碎片），其他索引会受到影响。
如果您的聚集索引在碎片中运行，您将不得不不时修复它。这需要对数据进行巨大的物理转移，应尽可能避免。

Normal 索引相当小。它们涵盖 - 简单地说 - 一个排序列表，以及用于快速访问实际行（包括所有列）的 PK。

所以 - 将所有这些放在一起：您应该有一个使用非碎片列的聚集主键索引。此外，您可以根据需要使用尽可能多的索引，覆盖（并包括）查询中需要的列。

有可能多列PK的好理由，有时这可能是最好的选择。但一般建议是：使用序列作为（集群）PK 并放置额外的索引来支持您的查询。

在任何情况下，这都不是绝对最快的方法，而是一种非常好的为所有人服务方法。

还有一点：如果表有一些共同点，则可以最好地支持许多编程方法。例如。 ID 列或类似 InsertDateTime 的内容。这允许更通用的编程方法。

更新：添加到您的评论...

在上面的评论中，您说：“......然后在以后有数百万条记录时遇到问题”。此类问题最好通过分区表、过滤索引和/或归档策略来解决...

UPDATE2：很好地考虑sargability...

在您的问题中，您写“由于每天都会有很多记录，所以我的一部分想要每天按顺序写入数据”。您对列执行的大多数操作都会破坏索引的使用（请阅读sargability）。但是 CAST() 或 DATETIME 到 DATE 将允许过滤日历天而不会造成性能损失。像WHERE CAST(InsertDateTime AS DATE) ='20190909' 这样的东西可以通过InsertDateTime 上的索引快速运行。

【讨论】：

我的目标是从人群中了解他们对这种方法的看法。感谢您的解释和花时间回复。我正在考虑使用无符号整数。