Quale sarebbe il modo migliore per implementare una struttura dati ad albero personalizzabile (ovvero una struttura ad albero con un numero sconosciuto di livelli) in un database?Struttura database per struttura dati ad albero
L'ho fatto una volta prima di utilizzare una tabella con una chiave esterna a se stessa.
Quali altre implementazioni riuscite a vedere e questa implementazione ha senso?
Lei parla il più comunemente implementato, che è adiacenza Lista: https://blogs.msdn.microsoft.com/mvpawardprogram/2012/06/25/hierarchies-convert-adjacency-list-to-nested-sets
Ci sono altri modelli come pure, tra percorso materializzato e set nidificati: http://communities.bmc.com/communities/docs/DOC-9902
Joe Celko ha scritto un libro su questo soggetto, che è un buon riferimento da una prospettiva SQL generale (è citato nel link all'articolo nidificato sopra).
Inoltre, Itzik Ben-Gann ha una buona panoramica delle opzioni più comuni nel suo libro "Inside Microsoft SQL Server 2005: query T-SQL".
Le cose principali da considerare quando si sceglie un modello sono:
1) frequenza di cambiamento della struttura - come spesso fa, la struttura stessa del cambiamento albero. Alcuni modelli forniscono migliori caratteristiche di aggiornamento della struttura. È tuttavia importante separare le modifiche alla struttura da altre modifiche dei dati. Ad esempio, potresti voler modellare l'organigramma aziendale. Alcune persone modelleranno questo come un elenco di adiacenza, utilizzando l'ID dipendente per collegare un dipendente al proprio supervisore. Questo è di solito un approccio non ottimale. Un approccio che spesso funziona meglio è quello di modellare la struttura organizzativa separata dai dipendenti stessi e mantenere il dipendente come un attributo della struttura. In questo modo, quando un dipendente lascia la società, la stessa struttura organizzativa non ha bisogno di essere modificata, solo l'associazione con il dipendente che ha lasciato.
2) L'albero è pesante come la scrittura o pesante, alcune strutture funzionano molto bene durante la lettura della struttura, ma comportano un sovraccarico aggiuntivo durante la scrittura sulla struttura.
3) Quali tipi di informazioni è necessario ottenere dalla struttura: alcune strutture eccellono nel fornire determinati tipi di informazioni sulla struttura. Gli esempi includono trovare un nodo e tutti i suoi figli, trovare un nodo e tutti i suoi genitori, trovare il conteggio dei nodi figli che soddisfano determinate condizioni, ecc.Devi sapere quali informazioni saranno necessarie dalla struttura per determinare la struttura che meglio si adatta alle tue esigenze.
Ciao, sto affrontando esattamente lo stesso problema indicato nella domanda e vorrei farti una domanda sugli argomenti di cui sopra. Considerando una struttura come nell'argomento numero uno (tabella strutturata organizzativa (non dipendente strutturata) con ParentId referenziato nella stessa tabella), ho bisogno di impostare chi è il capo di una determinata area. Assegnerò tutti i dipendenti di quella specifica area direttamente ad essa. Dove metteresti il capo di quella specifica area? Dentro la stessa area o un altro sopra? Il mio approccio è di riferirgli al gruppo di cui sopra, che mi dà una struttura migliore, penso. Grazie. –
Il primo collegamento sembra essere rotto. –
@J. C. Leitão - Grazie, ho aggiornato il link. – JeremyDWill
Dai un'occhiata allo Managing Hierarchical Data in MySQL. Descrive due approcci per l'archiviazione e la gestione di dati gerarchici (ad albero) in un database relazionale.
Il primo approccio è il modello di elenco di adiacenza, che è quello che essenzialmente si descrive: avere una chiave esterna che si riferisce alla tabella stessa. Mentre questo approccio è semplice, può essere molto inefficiente per alcune query, come la costruzione dell'intero albero.
Il secondo approccio discusso nell'articolo è il modello di serie nidificato. Questo approccio è molto più efficiente e flessibile. Fare riferimento all'articolo per una spiegazione dettagliata e query di esempio.
il tuo link ha un argomento molto interessante essere discusso. Grazie! – Fritz
Avere un tavolo con una chiave esterna ha senso per me.
È quindi possibile utilizzare un'espressione di tabella comune in SQL o la connessione da istruzione precedente in Oracle per creare il proprio albero.
Ho una tabella di registro, con una colonna Identità LogID e una colonna ParentLogID con un FK che rimanda alla colonna LogID. Quando viene scritta la prima riga di registro in una transazione, acquisisco SCOPE_IDENTITY(). Tutti gli altri record di log vengono scritti con questo valore nella colonna ParentLogID. Questo è veramente utile per raggruppare le righe che appartengono insieme. È l'unico modo reale per vedere cosa è successo, senza questo, sarebbe un enorme pasticcio di righe di registro da più transazioni tutte mescolate insieme. –
@ KM - Ha detto che "ha senso" non "non ha senso" –
Ho usato la seguente implementazione su SQL Server 2005. check here
fantastica collezione di pronto ad utilizzare le funzioni che possono essere utilizzate con il modello di lista di adiacenza per rendere la vita più semplice.
http://www.artfulsoftware.com/mysqlbook/sampler/mysqled1ch20.html
Se è necessario utilizzare database relazionale per organizzare struttura dati ad albero poi PostgreSQL ha modulo ltree fresco che prevede tipo di dati per rappresentare le etichette di dati memorizzati in una struttura gerarchica ad albero. È possibile ottenere l'idea da lì. (Per ulteriori informazioni consultare: http://www.postgresql.org/docs/9.0/static/ltree.html)
In comune LDAP viene utilizzato per organizzare i record nella struttura gerarchica.
Vedere: [Quali sono le opzioni per l'archiviazione dei dati gerarchici in un database relazionale?] (Http://stackoverflow.com/questions/4048151/what-are-the-options-for-storing-hierarchical-data-in -a-relazionale-database) – cbare
SQL Server (dal 2008) offre il [tipo di dati hierarchyid] (https://msdn.microsoft.com/en-us/library/bb677290.aspx) – BornToCode