Alguém está usando HierarchyId em produção real com tabelas de tamanho razoável, mais do que alguns milhares de linhas? É confiável / com desempenho? Até o momento, não encontrei ninguém não afiliado ao fornecedor que o recomende e Paul Nielsen desaconselha isso aqui .
Qual é a sua experiência com o uso do HierarchyId em sistemas de produção reais?
Quais critérios você usou ao escolher o HierarchyId em vez de suas alternativas?
Respostas:
Eu implementei o HierarchyID e achei que ele oferece bom desempenho e fácil de usar.
Usei-o em conjuntos de dados relativamente pequenos (dezenas de milhares de linhas) com hierarquia de até 10 ramos de profundidade.
Por que usar isso? O tipo HierarchyID fornece vários métodos auxiliares (como IsDescendantOf) que facilitam seu trabalho do que rolar seu próprio caminho materializado.
O comentário de Paul Nielsen sobre o StackOverflow é confuso para mim - o HierarchyID é um caminho materializado. Estou mais inclinado a concordar com este comentário abaixo da resposta dele.
Uma pergunta melhor pode ser 'por que não usá-lo'? É fácil de usar, fornece muitas funcionalidades que você escreveria para si mesmo e tem bom desempenho (nos meus testes limitados).
Esta é uma resposta à pergunta de Kirk 'por que não usá-lo (HierarchyId)'. Em comparação com o caminho materializado, em alguns casos importantes, o HierarchyId parece ter menos desempenho e menos conveniente para trabalhar.
O motivo é simples: citando o comentário da Microsoft no Connect , "O problema é que as chamadas CLR, incluindo os métodos de hierarchyID, são opacas ao otimizador de consultas. Isso ocorre por design. No entanto, isso significa que a estimativa de cardinalidade para elas às vezes pode ser bastante errado."
Por outro lado, implementar o caminho materializado é muito fácil na primeira vez que precisamos fazê-lo, e da próxima vez é essencialmente uma tarefa de copiar e colar. Portanto, obtemos uma solução mais versátil e com melhor desempenho com muito pouco esforço.
Portanto, concordo plenamente com Paul Nielsen, que escreveu em seu excelente livro intitulado "Microsoft® SQL Server® 2008 Bible" da seguinte maneira: "O novo HierarchyID não é isento de controvérsias. É novo e ganha bastante tempo na imprensa e na demonstração, mas eu ' não tenho certeza se é um problema que precisa de outra solução. "
Minha empresa usa o HeirachyID em vendas diretas, software de marketing multinível. Funciona. Eu realmente não fiz nenhum trabalho com isso, apenas sei que estamos usando.
O maior problema que já vi é que estamos percorrendo os níveis de maneira repetitiva, em vez de sermos mais baseados em conjuntos. Nessa área, o desempenho não é muito bom para nós, mas não tenho certeza se isso é um problema com o tipo ou com a nossa implementação.
Um problema com o hierarchyid é que você obtém o bloqueio do fornecedor. Mas encontrei um ótimo artigo de Adam Milazzo sobre como tudo funciona internamente:
http://www.adammil.net/blog/view.php?id=100
Com isso, consegui escrever um script do Postgres para converter meu conjunto de dados do MSSQL. Também o incluí em um script que escrevi para importar o banco de dados AdventureWorks para o Postgres:
https://github.com/lorint/AdventureWorks-for-Postgres
Basta procurar por "hierarchyid" no arquivo install.sql e você encontrará em breve referências para convertê-lo.
Nossa equipe o implementou na produção; no início, o desempenho é bom; após 2 anos, a tabela agora contém 430.000 linhas e o getroot e o getdecendent levam 3 segundos, sendo necessários para calcular o próximo valor de ID para inserir o registro. Agora, uma única inserção de subárvore leva cerca de 16 segundos, o que não é aceitável.