/u/1830/acm.png?f=community)
Mijn afstudeerproject draait om een vrij complexe categoriestructuur, die potentieel (en hopelijk 
) vrij groot kan worden (honderden categoriëen, duizenden documenten). De view hierop zal iig een website zijn, misschien ook ooit nog wel een of andere xml-view.
Aangezien ik nu zo'n beetje met het Objectontwerp moet gaan beginnen wilde ik eerst nog wat ideëen te berde brengen voor ik enorm in de problemen raak met mijn huidige gedachtes erover
De categoriestructuur zal meerdere bomen van categoriëen bevatten, waar documenten aan gehangen kunnen worden. Documenten kunnen aan meerdere categoriëen hangen en hoeven ook niet perse aan leaf-categoriëen te zijn gekoppeld.
De eerste gedachte voor een OO-structuur hiervoor is vrij simpel, je neemt een Categorie, geeft die een of andere List met childcategoriëen en een andere List met documenten. Eventueel doe je de omgekeerde mapping er ook nog bij, dus een Categorie geef je een parent en een Document een List met categoriëen waar ie bij hoort.
Maar dan komt het doorzoeken van en het browsen in de structuur.
Bij de presentatie van de boom wil ik alleen die (sub)categoriëen en "filter"categoriëen laten zien die ook daadwerkelijk naar een (pad naar een) document leiden. En uiteraard moet ook maar een bepaald niveau van categoriëen getoond worden, de complete set bomen in een webpagina verwerken lijkt me niet zo handig
Of een categorie naar een document zal leiden hangt af van de plek in de boom en de andere categoriebomen af. Ik hoop dat dit plaatje dat wat beter illustreert:
Als de blauwe categorie geselecteerd is tijdens het browsen, dan zijn de twee linkse documenten bereikbaar en moeten de beide subcategoriëen getoond worden.
Bij een selectie van de oranje categorie is het oranje gebied zichtbaar (vergeet die samenstelling maar even, das alleen maar extra complexiteit die niet zo relevant is).
Zodra de beide "filters" gekozen zijn, is alleen nog het rode document bereikbaar en mag dus uit het blauwe gebied de blauwe categorie en de subcategorie die aan het rode document vastzit getoond worden en uit het oranje gebied alleen de oranje categorie zelf.
De simpele manier om dit in een OO-oplossing te verwerken, lijkt me, is om per selectie een lijst van documenten te maken en daar dan een intersectie van te nemen. Deze klinkt mij alleen totaal niet efficient in de oren, zeker niet als ik dat zelf in Java ga lopen implementeren.
Nu heb ik een test opstelling met php5 en de opslag in (Postgre)SQL, de complexiteit van de selectie van de relevante documenten en categoriëen zit verwerkt in een paar complexe queries met elk de nodige subqueries. Om dat enigszins efficiënt te houden heb ik al gebruik "moeten" maken van een paar hulptechnieken (nested set van Joe Celko, een soort transative closure (welk document is vanaf welke categorie bereikbaar) en dat allebij weer dmv triggers aan de originele structuur gehangen).
Hoewel het werkt, ben ik niet zo weg van de complexiteit van de SQL-statements (meerdere pagina's aan tekst als ik het netjes formatteer) en de structuur is ook niet de allermooiste.
Voor de SQL-oplossing zie ik eigenlijk nauwelijks openingen voor verbeteringen, de recursieve queries zijn al overboord gegooid en de performance is nu al alleen te bereiken door de (redundante) extra tabellen.
Een idee dat ik heb is om de documentrepresentaties in een Xapian-database te stoppen en daar met Xapian-queries in te gaan graven (en dan dus de lijsten als tekstvelden beschouwen en dat soort dingen). Een Xapian DB is eigenlijk één grote B+-tree waar alle identifiers voor documenten (categoriëen, documenttypen, etc) allemaal in verzameld zijn, aangezien ik ook met keywords zal gaan werken en Xapian daar dan weer flink in uitblinkt is dat weer een voordeel. Maar Xapian kent geen hiërarchische structuren en het updaten van documenten is niet bijster handig te regelen daarin, dus dan moet ik voor de categoriëen alsnog een aparte representatie voor gaan geven. Hoewel er dan niet zoveel noodzaak is om dat in een rdms te steken en daar op complexiteit bespaard zou kunnen worden.
Een ander idee is om een Object database te nemen, dat lijkt heel goed met hiërarciëen te werken, maar ik zou dus niet weten hoe dat uitpakt met het nemen van intersecties van documentlijsten.
Iemand die mij tips kan geven en/of een ander idee heeft hoe ik deze structuur kan representeren en schaalbaar kan doorzoeken/browsen?
) vrij groot kan worden (honderden categoriëen, duizenden documenten). De view hierop zal iig een website zijn, misschien ook ooit nog wel een of andere xml-view.Aangezien ik nu zo'n beetje met het Objectontwerp moet gaan beginnen wilde ik eerst nog wat ideëen te berde brengen voor ik enorm in de problemen raak met mijn huidige gedachtes erover
De categoriestructuur zal meerdere bomen van categoriëen bevatten, waar documenten aan gehangen kunnen worden. Documenten kunnen aan meerdere categoriëen hangen en hoeven ook niet perse aan leaf-categoriëen te zijn gekoppeld.
De eerste gedachte voor een OO-structuur hiervoor is vrij simpel, je neemt een Categorie, geeft die een of andere List met childcategoriëen en een andere List met documenten. Eventueel doe je de omgekeerde mapping er ook nog bij, dus een Categorie geef je een parent en een Document een List met categoriëen waar ie bij hoort.
Maar dan komt het doorzoeken van en het browsen in de structuur.
Bij de presentatie van de boom wil ik alleen die (sub)categoriëen en "filter"categoriëen laten zien die ook daadwerkelijk naar een (pad naar een) document leiden. En uiteraard moet ook maar een bepaald niveau van categoriëen getoond worden, de complete set bomen in een webpagina verwerken lijkt me niet zo handig
Of een categorie naar een document zal leiden hangt af van de plek in de boom en de andere categoriebomen af. Ik hoop dat dit plaatje dat wat beter illustreert:
Als de blauwe categorie geselecteerd is tijdens het browsen, dan zijn de twee linkse documenten bereikbaar en moeten de beide subcategoriëen getoond worden.
Bij een selectie van de oranje categorie is het oranje gebied zichtbaar (vergeet die samenstelling maar even, das alleen maar extra complexiteit die niet zo relevant is).
Zodra de beide "filters" gekozen zijn, is alleen nog het rode document bereikbaar en mag dus uit het blauwe gebied de blauwe categorie en de subcategorie die aan het rode document vastzit getoond worden en uit het oranje gebied alleen de oranje categorie zelf.
De simpele manier om dit in een OO-oplossing te verwerken, lijkt me, is om per selectie een lijst van documenten te maken en daar dan een intersectie van te nemen. Deze klinkt mij alleen totaal niet efficient in de oren, zeker niet als ik dat zelf in Java ga lopen implementeren.
Nu heb ik een test opstelling met php5 en de opslag in (Postgre)SQL, de complexiteit van de selectie van de relevante documenten en categoriëen zit verwerkt in een paar complexe queries met elk de nodige subqueries. Om dat enigszins efficiënt te houden heb ik al gebruik "moeten" maken van een paar hulptechnieken (nested set van Joe Celko, een soort transative closure (welk document is vanaf welke categorie bereikbaar) en dat allebij weer dmv triggers aan de originele structuur gehangen).
Hoewel het werkt, ben ik niet zo weg van de complexiteit van de SQL-statements (meerdere pagina's aan tekst als ik het netjes formatteer) en de structuur is ook niet de allermooiste.
Voor de SQL-oplossing zie ik eigenlijk nauwelijks openingen voor verbeteringen, de recursieve queries zijn al overboord gegooid en de performance is nu al alleen te bereiken door de (redundante) extra tabellen.
Een idee dat ik heb is om de documentrepresentaties in een Xapian-database te stoppen en daar met Xapian-queries in te gaan graven (en dan dus de lijsten als tekstvelden beschouwen en dat soort dingen). Een Xapian DB is eigenlijk één grote B+-tree waar alle identifiers voor documenten (categoriëen, documenttypen, etc) allemaal in verzameld zijn, aangezien ik ook met keywords zal gaan werken en Xapian daar dan weer flink in uitblinkt is dat weer een voordeel. Maar Xapian kent geen hiërarchische structuren en het updaten van documenten is niet bijster handig te regelen daarin, dus dan moet ik voor de categoriëen alsnog een aparte representatie voor gaan geven. Hoewel er dan niet zoveel noodzaak is om dat in een rdms te steken en daar op complexiteit bespaard zou kunnen worden.
Een ander idee is om een Object database te nemen, dat lijkt heel goed met hiërarciëen te werken, maar ik zou dus niet weten hoe dat uitpakt met het nemen van intersecties van documentlijsten.
Iemand die mij tips kan geven en/of een ander idee heeft hoe ik deze structuur kan representeren en schaalbaar kan doorzoeken/browsen?
:strip_icc():strip_exif()/u/5855/BDKAMZi.jpg?f=community)
/u/89535/crop56f4e5c063de4.png?f=community)
