2010-08-12 6 views
5

Il titolo potrebbe essere strano, ma probabilmente è perché non so nemmeno se sto facendo la domanda giusta.Che tipo di struttura dati dovrei usare per imitare un file system?

Quindi essenzialmente quello che sto cercando di costruire è un sistema di categoricalizzazione "breadcrumbish" (come una directory di file) in cui ogni nodo ha un genitore (eccetto per root) e ogni nodo può contenere dati o un altro nodo. Questo sarà usato per organizzare gli indirizzi e-mail in un database. In questo momento ho un sistema in cui puoi creare un "gruppo" e aggiungere indirizzi email a quel gruppo, ma sarebbe molto bello aggiungere un sistema organizzativo ad esso.

Questo (nella mia testa) è in un formato ad albero, ma non so quale albero.

Il problema che sto riscontrando è lo sviluppo tramite MySQL. È facile attraversare alberi che sono in memoria, ma nel database, è un po 'più complicato.


Immagine dell'albero: http://j.imagehost.org/0917/asdf.png


SELECT * FROM aziende: Store di Tim Hardware, 7-11, Kwik-E-Mart, Cub Foods, di Bob Fruttivendolo, CONGLOM- O

SELECT * FROM negozi di alimentari: Cub Foods, di Bob Fruttivendolo, conglom-O

SELECT * FROM grandi negozi di alimentari: conglom-O

SELECT * FROM Chiese: Chiesa di San Pietro, Chiesa di San Giovanni


credo che questo dovrebbe essere sufficiente informazioni in modo da poter descrivere con precisione qual è il mio obiettivo.

+0

Sei sicuro che si desidera rigorosamente un albero? Sembra che alcuni dei tuoi nodi possano apparire in più di un ramo (il che è come immaginerò comunque la categorizzazione - potenzialmente molti tag per ogni dato oggetto). Ad esempio, se avessi un'altra categoria in Business per "Grandi Imprese", non potrebbe apparire anche CONGLOM-O? –

risposta

3

Bene, ci sono alcuni modelli che è possibile utilizzare. Quale è giusto dipende dalle tue esigenze.

È necessario selezionare un nodo e tutti i relativi figli? Se è così, allora un Nested set Model (Scroll down to the heading) potrebbe andare meglio per te. La tabella sarà simile a questa:

| Name  | Left | Right | 
| Emails | 1 | 12 | 
| Business | 2 | 7  | 
| Tim's | 3 | 4  | 
| 7-11  | 5 | 6  | 
| Churches | 8 | 11 | 
| St. Pete | 9 | 10 | 

Allora, per trovare nulla al di sotto di un nodo, basta fare

SELECT name FROM nodes WHERE Left > *yourleftnode* AND Right < *yourrightnode* 

per trovare tutto sopra il nodo:

SELECT name FROM nodes WHERE Left < *yourleftnode* AND Right > *yourrightnode* 

Se solo si vuoi effettuare una query per un livello specifico, puoi fare un Adjacency List Model (Scoll down to the heading):

| Id | Name  | Parent_Id | 
| 1 | Email | null  | 
| 2 | Business | 1   | 
| 3 | Tim's | 2   | 

per trovare tutto sullo stesso piano, basta fare:

SELECT name FROM nodes WHERE parent_id = *yourparentnode* 

Naturalmente, non c'è nulla ti impedisce di fare un approccio ibrido che vi permetterà di ricerca tuttavia vuoi per la query a portata di mano

| Id | Name  | Parent_Id | Left | Right | Path    | 
| 1 | Email | null  | 1 | 6  |/    | 
| 2 | Business | 1   | 2 | 5  | /Email/   | 
| 3 | Tim's | 2   | 3 | 4  | /Email/Business/ | 

Davvero, è solo una questione di vostre esigenze ...

+0

Sì! Nested Set Model è esattamente quello che stavo cercando! Grazie a teuuuuuuuuuu! – MALON

0

Come sempre quando vedo domande sulla modellazione di alberi e gerarchie, il mio suggerimento è di ottenere una copia di Joe Celko's book on the subject. Presenta vari modi per modellarli in un RDBMS, alcuni dei quali sono abbastanza fantasiosi, e fornisce i pro ei contro per ogni modello.

0

Creare un oggetto Gruppo che ha un nome, molti indirizzi e-mail e un genitore, che può essere nullo.

1

Il modo più semplice per farlo sarebbe qualcosa di simile a questo:

Group 
    - GroupID (PK) 
    - ParentGroupID 
    - GroupName 

People 
    - PersonID (PK) 
    - EmailAddress 
    - FirstName 
    - LastName 

GroupMembership 
    - GroupID (PK) 
    - PersonID (PK) 

Questo dovrebbe creare una struttura dove si può avere gruppi che hanno gruppi di genitori e persone che possono essere membri di gruppi (o gruppi multipli) . Se una persona può essere solo un membro di un gruppo, quindi eliminare la tabella GroupMembership e inserire un ID gruppo nella tabella Persone.

Le query complesse contro questa struttura possono tuttavia risultare difficili. Esistono altri modi meno intuitivi per modellarlo e semplificare le query (ma spesso rendono gli aggiornamenti più difficili).Se il numero di gruppi è ridotto, il modo più semplice per gestire le query è spesso caricare l'intero albero dei gruppi in memoria, memorizzarlo nella cache e utilizzarlo per creare le query.

Problemi correlati