相关疑难解决方法(0)

我们在工作中遇到大量遗留存储过程的问题.你们推荐任何可以帮助你更好地理解这些程序的工具吗？某种逆向工程,它识别过程间依赖性和/或过程与表依赖性.可以是免费或商业工具.

谢谢!

当我在Oracle商店工作时,我认为CONNECT_BY是理所当然的.现在我不得不使用SQL Server 2005并且有一些讨厌的对象层次结构.具体来说,我们有一个自引用表,其中所有子记录都有一个父级id的列.目前,我们有一个视图,将子映射映射到层次结构中的级别,以及一个令人讨厌的查询,它将父母与子女联系起来.虽然这种方法有效,但它远非优雅和臭味.我只是好奇其他人如何从SQL Server 2005中检索分层数据.

我正在设计一个分层数据库结构的设计,该结构模拟包含产品的目录(这与此问题类似).数据库平台是SQL Server 2005,目录非常大(750,000个产品,4个级别的8,500个目录部分),但是相对静态(每天重新加载一次),所以我们只关心READ性能.

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

• 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),但它只是不工作:)

谢谢你的帮助

詹姆士