2009-12-16 9 views
11

Sono un novizio in SQL Server 2008 e appena introdotto in HierarchyId.Alcune domande su HierarchyId (SQL Server 2008)

Sto imparando da SQL Server 2008 - HIERARCHYID - PART I. Quindi, fondamentalmente sto seguendo la linea articolo di linea e mentre la pratica in SSMS ho scoperto che per ogni ChildId alcuni valori esadecimali sono generati come 0x, 0x58,0x5AC0 ecc

Le mie domande sono

  1. Cosa sono valori esadecimali?
  2. Perché questi sono generati e qual è il loro uso? Intendo dove posso usare quei valori hexa?
  3. Abbiamo alcun controllo su questi valori hexa? Voglio dire possiamo aggiornare ecc.
  4. Come determinare la gerarchia esaminando quei valori di hexa. Voglio dire come posso determinare quale è il genitore e quale è il bambino?

risposta

-3

ti lascio gli altri a risolvere i problemi specifici, ma vi dirò, che, IMO, il hierarchyid in SQL Server 2008 non è uno dei più grandi contributi di Microsoft a SQL Server. Sono complessi e in qualche modo imbarazzanti. Penso che troverete che per molte esigenze gerarchiche, le espressioni di tabelle comuni (CTE) funzionano alla grande.

Randy

+6

Suppongo ti riferisci a ricorsiva CTE, come CTE, in generale, non hanno nulla a che fare con le gerarchie. Anche in questo caso, questi due concetti non si escludono a vicenda e gerarchico ha prestazioni di gran lunga migliori rispetto a qualsiasi altro metodo che ho visto (quando indicizzato e usato correttamente). Una colonna gerarchico può anche essere combinata con altre colonne di tipo nested-set per eseguire query gerarchiche molto complesse con prestazioni di ricerca dell'indice. Direi che la tua critica è infondata; hierarchyid è in effetti uno dei tipi di dati meno utilizzati in SQL 2008. – Aaronaught

+2

Non è solo sottoutilizzato, è anche sottostimato. Non esiste alcun supporto per HierarchyId in LinqtoSQL o Entity Framework (il progettista dbml semplicemente non li toccherà). Questo è vero anche nel VS 2010 RC. –

+2

Per alcuni di noi, HierarchyId è un'aggiunta tanto necessaria a SQL. Elimina la necessità di molte query ricorsive e può offrire significativi guadagni di prestazioni se usato correttamente. – Mark

11

Tali valori esadecimali sono semplicemente una rappresentazione binaria del livello gerarchico. In generale, non dovresti usarli direttamente.

Si consiglia di verificare il seguente esempio, che a mio avviso dovrebbe essere auto-esplicativo. Spero che ti faccia andare nella giusta direzione.

Creare una tabella con un campo hierarchyid:

CREATE TABLE groups (
    group_name  nvarchar(100) NOT NULL, 
    group_hierarchy hierarchyid NOT NULL 
); 

Inserire alcuni valori:

INSERT INTO groups (group_name, group_hierarchy) 
VALUES 
    ('root',  hierarchyid::Parse('/')), 
    ('domain-a', hierarchyid::Parse('/1/')), 
    ('domain-b', hierarchyid::Parse('/2/')), 
    ('sub-a-1', hierarchyid::Parse('/1/1/')), 
    ('sub-a-2', hierarchyid::Parse('/1/2/')); 

query tabella:

SELECT 
    group_name, 
    group_hierarchy.ToString() 
FROM 
    groups 
WHERE 
    (group_hierarchy.IsDescendantOf(hierarchyid::Parse('/1/')) = 1); 
0

Adam Milazzo ha scritto un ottimo articolo sulle interiora di hierarchyid qui:

http://www.adammil.net/blog/view.php?id=100

In poche parole, non è significativo per lavorare con le cose in esadecimale dritto, ma piuttosto di convertire i numeri fuori binario. La ragione è che le cose non sono tagliate su confini di byte pari. Rappresentare un singolo nodo può essere di soli 5 bit se è uno dei primi quattro nodi. Diventa sempre più lungo man mano che vengono utilizzati più nodi, 6 bit ciascuno per i successivi 4 nodi, 7 bit ciascuno per i successivi 8 nodi, quindi salta a 12 bit ciascuno per i 64 nodi successivi! E poi fino a 18 bit ciascuno per il prossimo 1024.

Avevo bisogno di convertire un database in Postgres e ho scritto uno script che analizza questi valori esadecimali.È possibile controllare la versione che ho fatto per AdventureWorks qui, cercare "hierarchyid":

https://github.com/lorint/AdventureWorks-for-Postgres/blob/master/install.sql