10

Sto iniziando un nuovo progetto che ha alcuni dati gerarchici e sto osservando tutte le opzioni per l'archiviazione in un database al momento .dati gerarchici in un database: query ricorsiva vs tabelle di chiusura e database grafico

Sto utilizzando PostgreSQL, che consente query ricorrenti. Ho anche esaminato modelli di progettazione per database relazionali, come ad esempio closure tables e ho dato un'occhiata alle soluzioni di database grafico come neo4j.

Sto trovando difficile decidere tra quelle opzioni. Ad esempio: dato che il mio RDBMS consente le query ricorsive, avrebbe ancora senso utilizzare le tabelle di chiusura e in che modo si confronta alle soluzioni di database grafico in termini di manutenibilità e prestazioni?

Qualsiasi opinione/esperienza sarebbe molto apprezzata!

+1

Questa cosa del tavolo di chiusura è in realtà piuttosto ordinata. Non necessario se hai domande ricorsive, ma ancora abbastanza pulito. Grazie per averlo portato alla mia attenzione –

risposta

8

La tabella di chiusura insieme è ridondante se è possibile utilizzare le query ricorsive :)

penso che sia molto meglio avere un complicato query ricorsiva che si deve capire una volta che affrontare l'extra IO (e spazio su disco) di una tabella separata e trigger associati.

Ho effettuato alcuni semplici test con query ricorsive in postgres. Con poche milioni di righe nella tabella, le query erano ancora < 10 ms per restituire tutti i genitori di un determinato bambino. Anche il ritorno di tutti i bambini era veloce, a seconda del livello del genitore. Sembrava dipendere più dal fatto che il disco IO recuperava le righe piuttosto che la velocità della query stessa. Questo è stato fatto da un singolo utente, quindi non sono sicuro di come si comporterebbe sotto carico. Sospetto che sarebbe ancora molto veloce se puoi anche tenere la maggior parte del tavolo in memoria (e configurare postgres correttamente). Anche il clustering del tavolo per ID padre sembrava essere d'aiuto.

+0

Grazie, ho pensato che potesse essere così – tospo

+1

Grazie per i parametri di riferimento. –

+0

generalmente sono d'accordo, anche se vedi gli Antipattern SQL di Bill Karwin per una guida su quando potresti ancora voler usare un'alternativa all'approccio dell'elenco di adiacenza (dove parent_id è un campo) – Joffer

2

Il campo di livello ("profondità") della tabella di chiusura è ridondante. Ci vuole solo una query ricorsiva per calcolarlo. Questo su riassume.