sql-server - 分层数据结构设计(嵌套集)

Question

我正在设计分层数据库结构，该结构模拟包含产品的目录(这类似于 this question )。数据库平台是 SQL Server 2005，目录非常大(750,000 种产品，8,500 个目录部分，超过 4 个级别)但相对静态(每天重新加载一次)，因此我们只关心读取性能。

目录层次结构的一般结构是:-

• 1 级部分
  • 2 级部分
    • 3 级部分
      • 4 级部分(产品链接到此处)

我们正在使用嵌套集模式来存储层次结构级别并将存在于该级别的产品存储在单独的链接表中。所以简化的数据库结构将是

CREATE TABLE CatalogueSection
(
    SectionID INTEGER,
    ParentID INTEGER,
    LeftExtent INTEGER,
    RightExtent INTEGER
)

CREATE TABLE CatalogueProduct
(
    ProductID INTEGER,
    SectionID INTEGER
)

我们确实有一个额外的复杂性，因为我们有大约 1000 个不同的客户群体，他们可能会或可能不会看到目录中的所有产品。因此，我们需要为每个客户组维护一个单独的目录层次结构“副本”，这样当他们浏览目录时，他们只会看到他们的产品，而不会看到任何空白部分。

为促进这一点，我们维护了一个表格，其中包含从下面部分“汇总”的层次结构的每个级别的产品数量。因此，即使产品仅直接链接到层次结构的最低级别，它们也会一直计算到树上。这张表的结构是

CREATE TABLE CatalogueSectionCount
(
    SectionID INTEGER,
    CustomerGroupID INTEGER,
    SubSectionCount INTEGER,
    ProductCount INTEGER
)

那么，进入问题层次结构顶层的性能非常差。显示所选目录部分(和所有子部分)中“前 10 名”产品的一般查询需要 1 分钟左右的时间才能完成。在层次结构的较低部分，速度更快但仍然不够好。

我已经在所有关键表上放置了索引(包括适用的覆盖索引)，通过查询分析器、索引调优向导等运行它，但仍然无法让它执行得足够快。

我想知道设计是否存在根本性缺陷，还是因为我们拥有如此庞大的数据集？我们有一个合理的开发服务器(3.8GHZ Xeon，4GB RAM)但它就是不工作:)

感谢您的帮助

詹姆斯

Answer 1

使用闭包表。如果您的基本结构是具有字段 ID 和 ParentID 的父子结构，则闭包表的结构是 ID 和 DescendantID。换句话说，闭包表是一个祖先-后代表，其中每个可能的祖先都与所有后代相关联。如果需要，您可以包含一个 LevelsBetween 字段。闭包表实现通常包括自引用记录，即 ID 1 是 LevelsBetween 为零的后代 ID 1 的祖先。

例子: parent /子女
ParentID - ID
1 - 2
1 - 3
3 - 4
3 - 5
4 - 6

祖先/后代
ID - DescendantID - LevelsBetween
1 - 1 - 0
1 - 2 - 1
1 - 3 - 1
1 - 4 - 2
1 - 6 - 3
2 - 2 - 0
3 - 3 - 0
3 - 4 - 1
3 - 5 - 1
3 - 6 - 2
4 - 4 - 0
4 - 6 - 1
5 - 5 - 0

该表旨在消除递归连接。您将递归连接的负载插入 ETL 循环，就像您每天加载一次数据时所做的那样。这将它从查询中移开。

此外，它还允许可变级别的层次结构。你不会被困在 4 点。

最后，它允许您在非叶节点中放置产品。许多目录在层次结构的较高级别创建“杂项”存储桶，以创建叶节点以将产品附加到。您不需要这样做，因为中间节点包含在闭包中。

就索引而言，我会在 ID/DescendantID 上做一个聚集索引。

现在是查询性能。这需要一个大块但不是全部。你提到了“前 10 名”。这意味着对您未提及的一组事实进行排名。我们需要细节来帮助调整这些。另外，这只会获取叶级部分，而不是产品。至少，您的 CatalogueProduct 应该有一个按 SectionID/ProductID 排序的索引。我会根据您提供的基数强制将 Section 到 Product 连接设为循环连接。目录部分的报告将转到闭包表以获取后代(使用聚集索引查找)。然后，该后代列表将用于通过循环索引查找使用索引从 CatalogueProduct 获取产品。然后，使用这些产品，您将获得进行排名所需的事实。