Como posso representar com eficiência a herança em uma árvore?

Eu tenho um banco de dados com três "níveis" de objetos: A, Be C. A tabela Atem cerca de 100.000 linhas, Btem 500.000 e Ctem 2 milhões.

Em um ataque de estupidez, projetei o banco de dados para usar tabelas de junção ABe BC, embora sejam 1:me poderiam ter sido representados como um ParentAatributo em Be um ParentBatributo em C. Fiz isso porque pensei na época que esses poderiam ser m:m.

Agora, também tenho uma tabela Dque tem relacionamento am:m com C. Para simplificar o gerenciamento de dados para os usuários, faz sentido permitir que eles se relacionem Dou A, Bem vez de diretamente, cada um deles C.

Então, eu tenho tabelas DAde junção , DBe DC, e uma visão de junção DC2que inclui DC, bem como as DCrelações herdadas das junções de DA-AB-BCe DB-BC. Eu uso um UNION ALL para isso e há alguma lógica de negócios para impedir que os usuários atribuam o mesmo Dregistro em dois níveis.

O problema é que o desempenho de DC2kinda suga. Todas as outras tabelas têm índices de cobertura apropriados para essas junções e os índices de cobertura são agrupados. DC2 não inclui tabelas A, B, Cou D, apenas as tabelas de união.

Há também as tabelas E, F, G e H que são semelhantes a D em como se relacionam com A, B e C.

Quais são algumas estratégias que posso usar para melhorar o desempenho desses relacionamentos herdados?

Já pensou:

• Criar DC2uma exibição indexada não é uma opção, pois UNION não é permitido em uma exibição indexada no MSSQL.
• Eu poderia fazer do DC2 uma tabela e gerenciá-lo com gatilhos, mas isso seria uma dor de cabeça e ainda tenho que lidar com EC2, FC2 etc. não consigo onde
• Mudar AB e BC em atributos de B e C pode, na verdade, desacelerar as coisas, já que as tabelas de junção são mais leves e as tabelas principais não são unidas a DC2 com frequência.