Alguém está usando HierarchyId em produção real com tabelas de tamanho razoável, mais do que alguns milhares de linhas? É confiável/desempenho? Até agora, não encontrei ninguém não afiliado ao fornecedor que o recomendasse, 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 HierarchyId em vez de suas alternativas?
Implementei o HierarchyID e descobri que ele oferece bom desempenho e é fácil de usar.
Eu o usei em conjuntos de dados relativamente pequenos (dezenas de milhares de linhas) com hierarquia de até 10 ramificações.
Por que usá-lo? O tipo HierarchyID fornece vários métodos auxiliares (como
IsDescendantOf) que tornam seu trabalho mais fácil do que rolar seu próprio caminho materializado.O comentário de Paul Nielsen no StackOverflow é confuso para mim - o HierarchyID é um caminho materializado. Estou mais inclinado a concordar com este comentário abaixo de sua resposta.
Uma pergunta melhor pode ser 'por que não usá-lo'. É fácil de usar, fornece muitas funcionalidades que, de outra forma, você escreveria para si mesmo e tem um bom desempenho (em 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, HierarchyId parece ter menos desempenho e ser menos conveniente para trabalhar.
O motivo é simples: citando o comentário da Microsoft em Connect , "O problema é que as chamadas CLR, incluindo os métodos de hierarquiaID, são opacas para o otimizador de consulta. Isso ocorre por design. No entanto, 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, na próxima vez, é essencialmente uma tarefa de copiar e colar. Assim, obtemos uma solução mais versátil e de 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" o seguinte: "O novo HierarchyID gera controvérsias. É novo e recebe muito tempo na imprensa e nas demonstrações, mas Não tenho certeza se é um problema que precisa de outra solução."
Minha empresa usa HeirachyID em vendas diretas, software de marketing multinível. Funciona. Eu realmente não fiz nenhum trabalho com ele, só sei que estamos usando.
O maior problema que vi com isso é que estamos iterando os níveis em um estilo de loop, em vez de ser mais baseado em conjuntos. Nessa área, ele não funciona muito bem para nós, mas não tenho certeza se isso é um problema com o tipo ou com nossa implementação.
Um problema com a hierarquiaid é 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 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 logo você encontrará referências para convertê-lo.
Nossa equipe o implementou em produção, a princípio o desempenho é bom, depois de 2 anos, a tabela agora contém 430.000 linhas e getroot e getdecendent leva 3 segundos, ambos são 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.