0

我计划一个数据库模式来存储亚马逊产品属性和额外的市场特定值（如标题、艺术家、重量等）

到目前为止，有一个带有列的Products表。GTIN varchar(13) (PK)在我的特定情况下，GTIN 可能是 EAN/UPC/ISBN 标识符。Products 中还有一ASIN char(10)列将 GTIN 与 ASIN 关联。

以编程方式捕获并正确处理同一 ASIN 的 EAN 和 UPC 时的行为，因此请认为所有 ASIN 都是唯一的。我定义了一个UNIQUE NONCLUSTERED CONSTRAINTonASIN并将其与 Products 表相关联为one-to-many。

第二个表ProductsData定义ASIN char(10) (FK)和 mid tinyint（市场 ID）。所有 ASIN 都与各自的市场 ID 一起存储：

rowid    ASIN          mid
1        B0002DB5GS    1
2        B0002DB5GS    44
3        B0002DB5GS    39
4        B0002Y4SYS    1
5        B0002Y4SYS    44
6        B0002Y4SYS    39

正如您所注意到的，还有一rowid int IDENTITY(1,1)列是虚拟的，但实现了唯一性。

假设以下事实：

  • 非常罕见的更新
  • 相对罕见的插入（每个添加的产品在事务中创建 3 条记录）
  • 没有删减
  • ASIN 列上的​​密集选择
  • rowid是一个假人，它只是确保唯一性。

这里有三个问题：

  1. 是否值得在和上创建复合索引？ASINmid
  2. 如果是，集群还是非集群？
  3. 我可以摆脱聚集索引，rowid因为我真的不需要它吗？
4

1 回答 1

1

根据您上面所说，如果性能是一个问题，并且我认为索引是解决方案，我将在ASIN和上实施非聚集覆盖索引mid。像这样的东西：

CREATE NONCLUSTERED INDEX IX_ASIN_COVERING_mid ON ProductsData (ASIN) INCLUDE (mid)

这样，当您加入ProductsData表时，您可以利用索引来提高性能，并且由于中间是“包含”的，它将与索引一起存储，并且查询引擎不需要更深入。

当然有很多前进的道路，但根据你的帖子，这是我倾向于的。希望能帮助到你！

所以总结一下你的问题

  1. 我的意见是使用覆盖索引而不是综合索引。这是因为这听起来像是您在 ASIN 之间的链接，Products而ProductsDatamid 只是顺其自然。因此，没有必要在索引中将其与 ASIN 组合在一起……包括它在这里会很好用——在我看来，它的设计目的是这样的。

  2. 非聚集索引如 1 所述，因为聚集索引应该是唯一的。此外，聚簇索引维护数据的顺序，因此如果您创建一个新产品并且其 ASIN 位于表中间的某个位置，则此处存在开销，因为 SQL Server 需要重新排序整个表

  3. 我认为您可以摆脱它...如果您没有将该列用于任何内容，并且它只是一个您不会在任何查询中使用的虚拟值，那么如果是我，我可能会放弃它。

于 2015-09-24T17:46:11.023 回答