Qualcuno usa HierarchyId nella produzione reale con tabelle di dimensioni ragionevoli, più di qualche migliaio di righe? È affidabile / performante? Finora non ho trovato nessuno che non sia affiliato con il venditore lo consiglia, e Paul Nielsen sconsiglia qui .
Qual è la tua esperienza con l'utilizzo di HierarchyId negli attuali sistemi di produzione?
Quali criteri hai usato quando hai scelto HierarchyId rispetto alle sue alternative?
Risposte:
Ho implementato HierarchyID e l'ho trovato per fornire buone prestazioni e facile da usare.
L'ho usato su set di dati relativamente piccoli (decine di migliaia di righe) con gerarchia profonda fino a 10 rami.
Perché usarlo Il tipo HierarchyID fornisce una serie di metodi di supporto (come IsDescendantOf) che semplificano il lavoro rispetto al percorso materializzato.
Il commento di Paul Nielsen su StackOverflow mi confonde: l'HierarchyID è un percorso materializzato. Sono più propenso a concordare con questo commento sotto la sua risposta.
Una domanda migliore potrebbe essere "perché non usarla". È facile da usare, offre molte funzionalità che altrimenti potresti scrivere per te stesso e si comporta bene (nei miei test limitati).
Questa è una risposta alla domanda di Kirk "perché non usarla (HierarchyId)". Rispetto al percorso materializzato, in alcuni casi importanti HierarchyId sembra essere meno performante e meno conveniente con cui lavorare.
Il motivo è semplice: citando il commento di Microsoft su Connect , "Il problema è che le chiamate CLR, inclusi i metodi di hierarchyID, sono opache per l'ottimizzatore delle query. Questo è di progettazione. Tuttavia, ciò significa che la stima della cardinalità per loro a volte può essere abbastanza sbagliato."
D'altra parte, l'implementazione del percorso materializzato è molto semplice la prima volta che dobbiamo farlo, e la prossima volta è essenzialmente un'attività di copia e incolla. Quindi, otteniamo una soluzione più versatile e dalle prestazioni migliori con il minimo sforzo.
Quindi sono completamente d'accordo con Paul Nielsen, che ha scritto nel suo eccellente libro intitolato "Microsoft® SQL Server® 2008 Bible" come segue: "Il nuovo HierarchyID non è senza controversie. È nuovo e ha un sacco di tempo per la stampa e la demo, ma io ' non sono sicuro che sia un problema che necessitava di un'altra soluzione. "
La mia azienda utilizza HeirachyID nelle vendite dirette, software di marketing multilivello. Funziona. Non ho davvero lavorato con esso, so solo che lo stiamo usando.
Il problema più grande che ho riscontrato è che stiamo ripetendo i livelli in modo continuo invece di essere più basati sui set. In quell'area non funziona molto bene per noi, ma non sono sicuro che si tratti di un problema con il tipo o la nostra implementazione.
Un problema con hierarchyid è il blocco del fornitore. Ma ho trovato un ottimo articolo di Adam Milazzo su come tutto funzioni internamente:
http://www.adammil.net/blog/view.php?id=100
Con questo sono stato in grado di scrivere uno script Postgres per convertire il mio set di dati da MSSQL. L'ho incluso anche in uno script che ho scritto per importare il database AdventureWorks in Postgres:
https://github.com/lorint/AdventureWorks-for-Postgres
Basta cercare "hierarchyid" nel file install.sql lì e presto troverai riferimenti per convertirlo.
Il nostro team lo ha implementato in produzione, inizialmente le prestazioni sono buone, dopo 2 anni, la tabella ora contiene 430.000 righe e getroot e getdecendent richiede 3 secondi, entrambi sono necessari per calcolare il prossimo valore ID per l'inserimento del record. Ora un singolo inserimento di sottostruttura richiede circa 16 secondi, il che non è affatto accettabile.