Ako sam te dobro razumeo, treba da stavis u neku tabelu strukturu foldera.

Ono sto bi trebalo da ti pomogne je da napravis jednu tabelu koja ce da sadrzi
polje "root..." sa ID-om glavnog foldera, polje "subfold..." sa ID-om subfoldera
i polje "namesub..." sa nazivom subfoldera.

Select iz ovakve tabele bi bio jednostavan.

Pozdrav !

Imaš više načina da skladištiš folder strukturu u bazi. Najjednostavnija za tovarenje je:

FolderID int identity
ParentID int (autoreference na FolderID)
FolderName nvarchar(xxx)

gde ćeš root folder da ubaciš kao parent samom sebi. Strutkura je veoma efikasna, lako se širi i po horizontali i vertikali i omogućava neke komplikovane akcije kao što je MOVE celog stabla nekog foldera sa jednog mesta na drugo. Ovaj sistem je zapravo preslikan realni file-sistem.
Problem sa ovom strukturom je selektovanje određene vrste podataka, npr. "daj mi sve foldere 3 nivoa", "daj mi punu putanju svih krajnjih foldera" Struktura je rekurzivna pa joj SELECT ne leži baš najbolje. Problem je i multi-level parenting, tj. ako je folder A ćaća B-u a B ćaća C-u i ti sa update uradiš MOVE tako da C postane ćale od B, B i C će pokazivati jedan na drugog a niko neće pokazivati na njih, tako da će postati siročići, dakle potrebno je i u samom kodu održavati integritet podataka.

Druga alternativa je tabela:

FolderPosition int
FolderName nvarchar(xxx)

root folder nije prisutan (ili mu je position = NULL). Svi folderi prvog nivoa imaju position od 1-9, drugog nivoa od 10-99, trećeg 100-999. Roditeljstvo se uspostavlja stepenom desetke, tj. folderu čiji je position 234, parent je folder 23, a njemu folder 2. Ograničenja po horizontali su očigledna (max 9 foldera u root-u, svaki folder maximalno 10 podfoldera), ali se ovo može proširiti na uštrb vertikalnog ograničenja, tako što ćete parenting raditi po stepenu većem od 10 (recimo hex, 16)
Pošto svaki folder nosi svoju poziciju ne treba rekurzija da bi se odredio nivo određenog foldera i može se lako doći do bilo kog foldera iznad njega. Problem je što nikakav SQL referential integrity ovde ne pomaže, sve mora da se održava u kodu. Inače, ovaj sistem koristi 99% knjigovodstvenog softvera koji sam video kod nas da opiše sintetiku i analitiku (uglavnom se koriste stringovi za position), samo što je kod za održavanje integriteta uglavnom nepostojeći/loš.

U svakom slučaju ovo je jedna od retkih situacija u kojima može da se kaže "reduntantnost je dobra". Po svojoj prirodi ove baze se mnogo više čitaju nego što im se menja sadržaj tako da je ekstra vreme utrošeno da se stvore redundantni podaci i da se softverski održi integritet između tih redundantnih podataka se višestruko isplati u brzini vađenja informacija. Dakle, stavi na papir SVE query-e koje hoćeš da imaš (opisno), onda za svaki izvuci neki metod koji će ti omogućiti brzo izvršavanje i onda sva "skupa" polja ma koliko redundantna bila ubaci u tabelu i napravi dobar kod za insert/update.

A mozda ti je najjednostavniji nacin (doduse slican drugom mmixovom resenju) da u jednom polju drzis ceo path (i eventualno nivo u jednom int polju). jeste redundantno, ali je brzo. Pod uslovom da ti nazivi foldera nisu predugacki.

Mogu ti preneti svoja iskustva.
Radio sam na oba navedena nacina (mmix - hvala na elaboraciji), sa tim da sam za manipulaciju clanovima strukture u aplikacijama koristio treeview kontrolu - koja sama po sebi vec ima ugradjene kontrolne mehanizme (jedinstvena vrednost svakog node-a, nije moguc crossreference, nivoi, putanje ...).
Procedura je bila:
1.Rekurzivno punjenje treeview-a iz tabele
2.Korisnik manipulise podacima
3.Ako korisnik zeli da sacuva izmene, cela struktura se vraca nazad u tabelu

Sve metode koje ste naveli su dobre kada se radi o brzom unosu medjutim citanje takve strukture je sporo. Pao mi je na pamet metod koji je optimizovan za brzo citanje, mana sa druge strane je relativno komplikovan unos i relativno komplikovan update ;).

Primer stabla(direktorijuma)

tablea dir ima (ID, ime), i tabela relacija ima (roditelj,dete,dubina)


tablea relacija


Problem je samo sto se za svaki direktorijum unosi n slogova gde je n njegova dubina. Ali lako dobijate primera radi direktorijume koji su podirektorijumi ili koji su nad direktorijumi datog direktorijuma itd... Vrednosti sa dubinom 0 i nisu morali da se unose ali ovako ubrzavaju stvari jos malo, ne morate sami explicitno da dodajete i taj direktorijum koji trazite ako vam treba.