Desvantagens

Montagem total / parcial da hierarquia

O modelo de caminhos materializados lida bem com boa parte das questões ligadas às relações hierárquicas. É possível obter informações tanto de níveis inferiores imediatos quanto dos inferiores não imediatos. No entanto, de uma forma geral, o modelo dos caminhos materializados é uma técnica bem adequada à navegação de cima para baixo (TOP-DOWN) mas não é muito eficiente para navegações de baixo para cima (BOTTOM-UP).

O centro de custo TI tem como identificador hierárquico 1.6. Como todos os seus níveis inferiores têm necessariamente o prefixo 1.6 é bem mais fácil elaborar uma consulta que relacione todos os lançamentos para o centro de custo TI sejam eles diretos ou indiretos já que todos os centros de custos subordinados à TI terão necessariamente o prefixo 1.6.

Um problema em potencial surge quando é necessário informações de níveis superiores. O centro de custo Copa, por exemplo, possui o identificador hierárquico 1.3.2.3. Visualmente é possível perceber que ele é subordinado indiretamente aos centros de custo Presidência e Administração e diretamente a Serviços Gerais, mas elaborar uma consulta em SQL que traga todas essas relações hierárquicas é algo praticamente impossível de ser feito sem repassar essa complexidade para a aplicação, utilizar comportamento procedural do lado do banco de dados ou ainda recorrer a extensões proprietárias. O comando abaixo demonstra uma forma de fazer essa pesquisa utilizando o Transact SQL.

DECLARE
    @NomeCentroCusto VARCHAR(80), @IdHierarquico VARCHAR(20)
SET @NomeCentroCusto = 'Copa'
SET @IdHierarquico = (SELECT IdHierarquico FROM CENTROSCUSTO WHERE NomeCentroCusto = @NomeCentroCusto)

WHILE LEN(@IdHierarquico) > 2
BEGIN
    SET @NomeCentroCusto = (SELECT NomeCentroCusto FROM CENTROSCUSTO WHERE IdHierarquico = @IdHierarquico)
    PRINT @NomeCentroCusto
    SET @IdHierarquico = LEFT(@IdHierarquico,LEN(@IdHierarquico)-2)
END

SET @IdHierarquico = LEFT(@IdHierarquico,1)
SET @NomeCentroCusto = (SELECT NomeCentroCusto FROM CENTROSCUSTO WHERE IdHierarquico = @IdHierarquico)

PRINT @NomeCentroCusto

Identificação da profundidade

O modelo dos caminhos materializados não é capaz de fornecer a profundidade da hierarquia (quantidade de níveis hierárquicos) e nem a profundidade até um determinado nó. No exemplo citado, o centro de custo Presidência tem profundidade 1, TI tem profundidade 2, Infra-estrutura possui profundidade 3, etc. Assim como no modelo adjacente, não é possível fornecer essa resposta apenas utilizando o padrão ANSI 92*. Somente através de extensões proprietárias é possível retornar essa informação em uma única setença SQL.

Desempenho

A utilização de colunas textuais costuma ser prejudicial para os otimizadores de consulta nos bancos de dados relacionais. A utilização do operador LIKE com o % apenas ao final pode fazer uso dos índices (em oposição ao péssimo desempenho da função SUBSTRING sobre uma coluna), mas mesmo assim não é uma situação muito performática já que a largura do índice comum em um campo texto é maior do que o normal.

Histórico

Assim como o modelo adjacente, o modelo dos caminhos materializados não é eficaz ao lidar com o histórico de uma hierarquia. Qualquer mudança em alguma relação hierarquia irá anular todos os registros atuais necessitando marcar todos como histórico e recriar toda a hierarquia. Se por exemplo, o centro de custo Infraestrutura for eliminado e os centros de custo Redes e Banco de Dados vincularem-se diretamente ao centro de custo TI, as relações "TI - Infraestrutura", "Infraestrutura - Redes" e "Infraestrutura - Banco de Dados" serão perdidas. Será necessário armazenar duas situações: a hierarquia da ARP antes dessa mudança e a hierarquia da ARP após essa mudança resultando em duas realidades. Basta uma outra mudança para resultar em uma terceira realidade. Manipular essas diferentes realidades em paralelo é uma tarefa extremamente trabalhosa embora nem sempre exigida. Muitas vezes não se deseja guardar esse tipo de informação em um histórico.

Regras de numeração

Para que consultas de referência ao superior imediato possam ser realizadas é preciso utilizar uma quantidade fixa de caracteres no sufixo do centro de custo. O centro de custo TI tem seu identificador igual a 1.6 enquanto o centro de custo Infraestrutura tem seu identificador igual a 1.6.2. Nesse caso todo sufixo de identificação deve ter um caractere. Se o centro de custo TI possuísse mais de 10 centros de custo inferiores imediatos (sugerindo uma identificação 1.6.10), o sufixo de identificação deveria ter dois caracteres. Nesse caso a identificação correta para o centro de custo TI seria 01.06 e para o centro de custo Infraestrutura seria 01.06.02. Isso é necessário para que a posição de sufixos de identificação seja conhecida (nesse último exemplo sempre os dois últimos caracteres).

* O padrão ANSI 92 é o implementado na maioria dos SGBDs convencionais. É possível que na elaboração de outros padrões (SQL 99 e SQL 2003) já estejam contempladas alternativas para trabalhar hierarquias.