schema del database con dati gerarchici illimitati che vengono modificati molto

Naviga le tue risposte
6

Sto provando a creare una sorta di app / forum di collaborazione con threading illimitato; nessuna differenza tra post, discussioni o forum. Qualsiasi post può avere una risposta illimitata, e lo stesso post può avere diversi bambini, che hanno diversi figli, e così via. Ogni post può anche avere diversi genitori. Il risultato finale sarebbe più simile a una mappa mentale di un forum, anche se l'uso come forum regolare sarebbe anche possibile.

Come vedo le persone che la usano: dire che un team discute la realizzazione di un sito web del progetto. Dopo alcuni thread, la conversazione si divide in conversazioni parallele su coding & design. Poi, dopo un po ', i due nodi finali vengono collegati. La conversazione continua per un po '... Anche una terza conversazione non correlata sui siti web in stile bauhaus viene collegata, per riferimento ... ecc.

In questo momento sto provando a costruire una dimostrazione di concetto, e sono a corto di scelta sulla progettazione del database da scegliere.

A quanto ho capito, ci sono due possibili modelli: il modello di lista di adiacenza e il modello di serie nidificato. E a quanto ho capito, il set annidato è solitamente preferito. Ho creato un'app basata sul modello del set annidato e so perché è più utile, nella maggior parte dei casi.

Qualcosa mi infastidisce qui però: dal momento che ho intenzione di avere molti utenti che aggiungono molte foglie su molti nodi diversi, e dal momento che il N.S.M. deve spostare a sinistra oa destra un intero mazzo di foglie ogni volta che viene aggiunto un fratello, quale sarebbe il mio schema di database migliore? Non intendo ancora rilasciare un'applicazione completamente ottimizzata, ma mi piacerebbe comunque iniziare con il piede giusto.

Ecco alcuni dei miei pensieri, vorrei opinioni su di loro:

  • Lascia molto spazio tra i nodi, così i nodi dei genitori sarebbero numerati 0, 10000, 20000, ecc. Questa non è una soluzione elegante, ma potrebbe funzionare
  • Tornare al modello dell'elenco di adiacenza e utilizzare una tabella node_node per collegare i nodi. Meno efficiente nel recupero degli alberi, ma più efficiente nell'aggiunta / eliminazione dei nodi
  • Elimina completamente i database e torna ai file, con un mix di directory / xml per memorizzare i dati. Non ho mai lavorato con i filesystem per recuperare e cercare grandi quantità di dati, non so come funzionerebbe fuori
  • C'è qualche schema DB più adatto al mio caso di cui sei a conoscenza?

Grazie in anticipo

    
posta Xananax 12.05.2011 - 01:25
fonte

5 risposte

2

Se sei disposto ad andare per gli elenchi di adiacenze, allora perché una chiave straniera semplice per il genitore di ogni post non fa al caso tuo?

In ogni caso, stai lontano dai set nidificati per le situazioni con molti inserimenti. Qualunque cosa tu faccia per cercare di mantenerla efficiente renderà le cose complesse e perderebbe ogni vantaggio che il trucco elegante avrebbe potuto avere.

E per l'amor di Dio, non andare in base ai file - finirai per reinventare il database da solo, male.

    
risposta data 12.05.2011 - 09:59
fonte
3

Mi sono divertito con il percorso materializzato con django-treebeard. Fondamentalmente memorizza il percorso completo per ogni livello di nidificazione, quindi puoi eseguire una selezione completa iniziando da una radice e ordinando in base al percorso per recuperare la gerarchia completa.

È più lento per inserti e nodi in movimento, ma la lettura è molto più veloce di ricorsione e CTE. Non mi preoccuperei troppo delle prestazioni qui. Anche se aggiungi molti post, sarai comunque in testa al gioco se la maggior parte delle azioni vengono lette (che nel caso di un forum sono di gran lunga).

Barbalbero immagazzina anche il numero di bambini e la profondità attuale in ogni record, ma quelli non sono strettamente necessari.

Ad esempio, questo è il modo in cui è memorizzato nel database 

path         item

0001         Item 1 (root)
00010001     Item 1.1  
00010002     Item 1.2
00010003     Item 1.3
000100030001 Item 1.3.1
00010004     Item 1.4
    
risposta data 12.05.2011 - 17:28
fonte
2

Perché siamo bloccati su database basati su SQL e incentrati sul tavolo per risolvere un problema triangolare? Senza dubbio andrò con qualcosa di schema-less e documento basato qui, specialmente per la fase di proof of concept in cui non si raddoppieranno tutte le principali modifiche in quanto non si avrà uno schema da modificare.

    
risposta data 12.05.2011 - 15:28
fonte
1

Stavo per commentare & upvote su un post che è appena stato cancellato, semplicemente per: "non fare file basati - finirai per reinventare il database da soli, male".

Spot on. Ho lavorato in una società che ha fatto questo, non era carina. Comincerai tutto bello e facile, sarà fantastico, penserai che i DB sono spazzatura e il tuo stupefacente.

Quindi dovrai aggiungere qualcosa di semplice che i DB faranno per te, e la prossima cosa saprai scrivere 5 pagine di codice Python solo per spostare un record da una posizione all'altra. Sono contento di non lavorare più lì.

    
risposta data 13.05.2011 - 10:41
fonte
0

Gli alberi binari sono fantastici se hai bisogno di una lista ordinata. Non hai bisogno di un elenco ordinato per questo progetto. Hai una catena di relazioni genitore-figlio anche conosciuta come un singolo elenco collegato, che può essere associato a un nodo radice. Questo nodo radice appartiene a una categoria.

Vorrei usare una chiave esterna per il ParentId che costruisce una catena. Vorrei anche usare un Foreign Key per il Root-Node per una rapida retrevial dell'intero thread.

Se un record figlio viene eliminato e ha il proprio record figlio, quel record figlio ParentId deve puntare al nuovo record padre.

    
risposta data 12.05.2011 - 12:57
fonte

Leggi altre domande sui tag

Questo pseudocodice di inserimento albero rosso-nero da Introduzione agli algoritmi (CLRS) è corretto? Qual è il datastore utilizzato da Google per Google Instant?