2009-02-23 15 views
6

Ho un database genealogico (relativo alle pecore in realtà), utilizzato dagli allevatori per la ricerca di informazioni genetiche. In ogni disco memorizzo padre e madre. In una tabella separata memorizzo le informazioni complete "roll-up" in modo da poter dire rapidamente l'albero genealogico completo di qualsiasi animale senza ricorrere nell'intero database ...Qualsiasi utente ha utilizzato il tipo HierarchialID di SQl Server 2008 per archiviare i dati genealogici

Recentemente scoperto il tipo hierarchicalID incorporato nel server SQL 2008, in la superficie sembra promettente, ma io e mi chiedo se qualcuno lo abbia usato abbastanza per sapere se sarebbe appropriato nel mio tipo di app (cioè due genitori, più figli)? Tutti i campioni che ho trovato/letto finora trattano relazioni di tipo manager/dipendente in cui un determinato capo può avere più dipendenti e ogni dipendente può avere un singolo capo.

Le esigenze della mia app sono simili, ma non proprio uguali.

Sono sicuro che scaverò comunque in questa nuova tecnologia, ma sarebbe bello scorciare la mia ricerca se qualcuno già sapesse che non è stato progettato in modo tale da consentirmi di farne uso.

Sono anche curioso di sapere che tipo di prestazioni le persone vedono utilizzando questo nuovo tipo di dati rispetto ad altri metodi che fanno la stessa cosa.

risposta

3

Non riesco a vedere come funzionerebbe; in una normale gerarchia, c'è una singola catena alla radice, quindi può memorizzare il percorso (che è ciò che il binario è) per ciascun nodo. Tuttavia, con più genitori, questo non è possibile: anche se dividi matriarcato e partiarcato, hai ancora 1 madre, 2 nonne, 4 pronipoti, ecc. (Senza nemmeno entrare in alcuni degli scaner più "interessanti" possibile, specialmente con il bestiame). Non esiste un singolo percorso logico da codificare, quindi no: non penso che questo possa funzionare nel tuo caso.

Sono felice di essere corretto, però.

+0

Questo è stato il mio primo pensiero ... ora sto cercando di mettere la mia testa sul concetto di albero come "capovolto". Cioè ogni bambino è un capo, e i genitori sono dipendenti ... non hanno ancora pensato bene di vedere se il modello tiene ... –

+2

Questo rende l'aggiunta molto costosa (dovresti ricalcolare tutto relativo ai nuovi agnelli) e probabilmente (non testato) non funziona ancora, a meno che non copri ogni pecora a un solo agnello ... –

+0

Non rovescerai questo albero? A partire dal bambino ai genitori, ai nonni ecc –

5

Supponendo che ogni pecora abbia un genitore maschio e un genitore femmina, e che nessuna pecora possa essere genitrice (portando a un paradosso temporale ovino), allora che ne è dell'utilizzo di due gerarchiati?

CREATE TABLE dbo.Sheep(
    MotherHID hierarchyid NOT NULL, 
    FatherHID hierarchyid NOT NULL, 
    Name int NOT NULL 
) 
GO 
ALTER TABLE dbo.Sheep 
ADD CONSTRAINT PK_Sheep PRIMARY KEY CLUSTERED (
    MotherHID, 
    FatherHID 
) 
GO 

Facendo loro un PK congiunta, si sarebbe identificare in modo univoco ogni pecora come il prodotto della sua gerarchia materna e paterna di gerarchia.

Potrebbe esserci qualche problema intrinseco in agguato qui, quindi procedere con cautela con un paio di semplici prototipi - ma inizialmente sembra che funzioni per voi.

2

Utilizzare due Gerarchia ID separati per indicare che padre e madre funzionerebbero correttamente.

Tuttavia, NON si vorrebbe assolutamente usarli come un indicatore unico della riga, poiché si tratta di una situazione 2-a-molti. (Due pecore possono avere più bambini.)

Non vedo nulla di intrinsecamente sbagliato nell'usare HierarchyId per ascendenza - almeno per Sheep. Per le persone, le relazioni sono molto più complicate di "questa persona ha generato quella persona", quindi ovviamente l'uso sarebbe limitato alla riproduzione.

0

SQL Server hierarchyID non è una soluzione affidabile per molte domande di analisi genealogiche. È basato su ORDPATH e l'ho usato per un po 'nella genealogia; ma ci sono troppi scenari nella genealogia che non possono essere prontamente affrontati con i metodi ORDPATH per i grafici aciclici diretti. Un database grafico è molto più robusto e adatto alla genealogia. Io uso Neo4j: http://stumpf.org/genealogy-blog/graph-databases-in-genealogy.

Problemi correlati