(ASP) Lus voor het uitlezen van categorieen

[Verwijderd]

Ik ben bezig met het maken van een CMS in ASP. Hiervoor wil ik een producten module maken, alleen ik kom er niet uit en heb de volgende vraag:

Ik gebruik een Access DB met de tabel 'Product', hierin de volgende velden:
'ProductID' = Autonummering van Product
'ParentID'= ID waar dit product aan gerelateerd is (is ook een product)
'Titel' = Titel van Product

Voorbeeld van tabel 'Product':
'1','0','Citroen'
'2','0','Peugeot'
'3','1','AX Onderdelen'
'4','2','307 Onderdelen'
'5,'3','AX Sportuitlaat'
'6,'4','307 Glazen Dak'
'7','5','Schroefje AX Sportuitlaat'

Hierbij is 'ParentID' = '0' een hoofdgroep, 'ParentID' = '1' gerelateerd aan 'ProductID' = '1', enz.

Nou wil ik een lus (met SQL of gewoon in ASP) maken die de volgende tabel/array maakt totdat hij alle subsubsub enz. onderdelen heeft gehad.
Citroen
-AX Onderdelen
--AX Sportuitlaat
---Schroefje AX Sportuitlaat
Peugeot
-307 Onderdelen
--307 Glazen Dak

Wie kan mij hierin helpen?

Groet,

DreamSky

[ Voor 24% gewijzigd door Verwijderd op 28-03-2003 14:33 ]

[gorgi_19]

Recursieve functie van maken. wdb zijn er genoeg voorbeelden te vinden. Wat heb je tot nu toe al, waar gaat het fout? Wat lukt je niet?

[momania]

Wat je beter kan dan ipv een hele lastige query hiervoor gaan verzinnen, is nog eens kijken naar de data die je wilt opslaan en dus beter normaliseren.
Het is beter als je een tabel als hoofdgroep maakt en per stap dat je dieper gaat (dus bv naar onderdelen), maak je daar een nieuwe tabel voor die je koppeld aan de hoofdgroeptabel.
Als je de data zo structureerd worden je queries ineens ook heel simpel.

[Verwijderd]

Ik heb al een functie gemaakt maar die leest alleen de hoofdgroep uit en de groep die aan de hoofdgroep is gerelateerd uit. Ik wil nu een functie die de hele database uitleest totdat hij alles heeft gehad.

Ik weet niet of je met ASP functies kunt overerven zoals met object georienteerde talen, maar dan zou je met een functie de rest kunnen uitlezen.

Maar dit weet ik niet dus ik zou graag weten of dit mogelijk is, of dat er een leuke functie voor is

[gorgi_19]

momania schreef op 28 maart 2003 @ 14:36:
Wat je beter kan dan ipv een hele lastige query hiervoor gaan verzinnen, is nog eens kijken naar de data die je wilt opslaan en dus beter normaliseren.
Het is beter als je een tabel als hoofdgroep maakt en per stap dat je dieper gaat (dus bv naar onderdelen), maak je daar een nieuwe tabel voor die je koppeld aan de hoofdgroeptabel.
Als je de data zo structureerd worden je queries ineens ook heel simpel.

Dit is dus niet de juiste methode. Dan krijg je voor 3 niveaus 3 tabellen.. MAar je weet niet hoeveel niveaus je wilt hebben.. De structuur is goed. Echter, je moet het imho niet gaan proberen om het in 1 query op te gaan lossen. Alles inlezen in een array, en deze vervolgens steeds gaan doorlopen, is imho wel een goede methode.

En de functie die moet je zelf maken, bestaat niet standaard.

[ Voor 4% gewijzigd door gorgi_19 op 28-03-2003 14:40 ]

[momania]

gorgi_19 schreef op 28 maart 2003 @ 14:39:
[...]

Dit is dus niet de juiste methode. Dan krijg je voor 3 niveaus 3 tabellen.. MAar je weet niet hoeveel niveaus je wilt hebben.. De structuur is goed. Echter, je moet het imho niet gaan proberen om het in 1 query op te gaan lossen. Alles inlezen in een array, en deze vervolgens steeds gaan doorlopen, is imho wel een goede methode.

En de functie die moet je zelf maken, bestaat niet standaard.

Ik heb iig geleerd om altijd zo weinig mogenlijk tabellen te laten verwijzen naar zichzelf.

[Verwijderd]

Ik denk dat het werken met arrays te omslachtig is en het moet op een andere slimmere manier kunnen. Ik heb ten eerste een functie die de hoofdgroepen uitleest :

Function WriteParentOptions()
sqlParent="SELECT * FROM Product WHERE ParentID = 0"
Set rsParent = Server.createObject("ADODB.Recordset")
rsParent.open sqlParent, dsn, 1, 2, &H0001

If( rsParent.RecordCount <> 0 ) Then
While Not rsParent.Eof Or rsParent.Bof
Response.Write(rsParent(2))
call WriteSubOptions(rsParent(0))
rsParent.MoveNext
Wend
rsParent.Close
Else
rsParent.Close
WriteParentOptions = False
End If
End Function

Deze functie die roept weer een andere functie aan: WriteSubOptions. Deze functie schrijft de onderliggende functies op het scherm:

Function WriteSubOptions( ID )
sqlSub="SELECT * FROM Product WHERE ParentID = "&Abs(ID)
Set rsSub = Server.createObject("ADODB.Recordset")
rsSub.open sqlSub, dsn, 1, 2, &H0001

If( rsSub.RecordCount <> 0 ) Then
While Not rsSub.Eof Or rsSub.Bof
Response.Write(rsSub(2)
rsSub.MoveNext
Wend
rsSub.Close
Else
rsSub.Close
WriteSubOptions = False
End If
End Function

Wat ik zou willen dat je zo'n functie kan overerven. Dat je dus binnen de functie dezelfde functie kan aanroepen. Dit zou heel makkelijk wezen.

Commentaar, Suggesties e.d. van harte welkom

[gorgi_19]

Arme database... 100 menuitems zijn 100 queries..

[ Voor 4% gewijzigd door gorgi_19 op 28-03-2003 14:58 ]

[Verwijderd]

daar zijn databases toch voor bedoeld! Anders hadden ze maar geen database moeten worden

[momania]

gorgi_19 schreef op 28 March 2003 @ 14:57:
Arme database... 100 menuitems zijn 100 queries..

Dat bedoelde ik dus met eerst goed normaliseren.
Tabellen die naar zichzelf verwijzen is leuk, maar als het te groot wordt krijg je te veel losse queries die achter elkaar afgeschoten worden en Acces vind dat al helemaal niet leuk

[gorgi_19]

momania schreef op 28 March 2003 @ 15:01:
[...]

Dat bedoelde ik dus met eerst goed normaliseren.
Tabellen die naar zichzelf verwijzen is leuk, maar als het te groot wordt krijg je te veel losse queries die achter elkaar afgeschoten worden en Acces vind dat al helemaal niet leuk

Maar dan staat er bij voorbaat dus al vast hoeveel niveaus je hebt.. En je verplaatsmogelijkheden worden ook enorm beperkt.

Verwijderd schreef op 28 March 2003 @ 15:00:
daar zijn databases toch voor bedoeld! Anders hadden ze maar geen database moeten worden

Databases zijn bedoeld om snel data in te zoeken. De hele tijd een query er op uitvoeren, kan imho vertragend werken.. Maar dat is iets om uit te testen.

[ Voor 28% gewijzigd door gorgi_19 op 28-03-2003 15:06 ]

[Verwijderd]

Kijk ik heb ook wel geleerd databases eerst door de 3 (of 4?) normaalvormen te gooien. Maar ik kan deze database niet echt normaliseren: er zit niet echt een herhalende groep in, etc etc..

Maar als je een goed voorstel hebt .. ik sta overal voor open

[Verwijderd]

Maar dan staat er bij voorbaat dus al vast hoeveel niveaus je hebt.. En je verplaatsmogelijkheden worden ook enorm beperkt.

Heb je dan nog een suggestie hoe je het dan wel zou moeten doen? Je weet wel steeds hoe het niet moet, dus zal je het ook wel weten hoe het wel moet

[gorgi_19]

Verwijderd schreef op 28 maart 2003 @ 15:11:
[...]


Heb je dan nog een suggestie hoe je het dan wel zou moeten doen? Je weet wel steeds hoe het niet moet, dus zal je het ook wel weten hoe het wel moet

gorgi_19 schreef op 28 maart 2003 @ 14:39:
[...]

Dit is dus niet de juiste methode. Dan krijg je voor 3 niveaus 3 tabellen.. MAar je weet niet hoeveel niveaus je wilt hebben.. De structuur is goed. Echter, je moet het imho niet gaan proberen om het in 1 query op te gaan lossen. Alles inlezen in een array, en deze vervolgens steeds gaan doorlopen, is imho wel een goede methode.

En de functie die moet je zelf maken, bestaat niet standaard.

[sandergar]

momania schreef op 28 March 2003 @ 14:36:
Wat je beter kan dan ipv een hele lastige query hiervoor gaan verzinnen, is nog eens kijken naar de data die je wilt opslaan en dus beter normaliseren.
Het is beter als je een tabel als hoofdgroep maakt en per stap dat je dieper gaat (dus bv naar onderdelen), maak je daar een nieuwe tabel voor die je koppeld aan de hoofdgroeptabel.
Als je de data zo structureerd worden je queries ineens ook heel simpel.

Dat bedoelde ik dus met eerst goed normaliseren.
Tabellen die naar zichzelf verwijzen is leuk, maar als het te groot wordt krijg je te veel losse queries die achter elkaar afgeschoten worden en Acces vind dat al helemaal niet leuk

10 niveaus dan 10 tabellen? En wat nu als er een aantal childs opeens verhuisd moeten worden onder een andere parent die zich op een ander niveau bevindt?

daar zijn databases toch voor bedoeld! Anders hadden ze maar geen database moeten worden

Niet echt ... Gebruik 1 SQL opdracht en sla het resultaat op in een recordset! Loop deze structuur door om je recursieve boom op te bouwen!

Heb zelf onlangs een recursieve opdracht uitgewerkt. Het kost even wat zoek werk maar uiteindelijk heb ik het zowel in VBA en in ASP voor elkaar gekregen. De volgende site heeft model gestaan voor mijn oplossing:
http://www.capastatistic.com/dev/samples/programming/vb/tree/vbtree.htm
En zoals Gorgi_19 zei: "de functie die moet je zelf maken, bestaat niet standaard." Heb is een kwestie van wat research en een beetje je hersenen laten werken!!!

[justmental]

Kan je database geen connect by queries?
Als je die hebt dan kun je het met een zo'n query oplossen.

[sandergar]

justmental schreef op 28 March 2003 @ 18:45:
Kan je database geen connect by queries?
Als je die hebt dan kun je het met een zo'n query oplossen.

Ben wel beniewd naar de query ... hoe gaat deze er dan ongeveer uitzien?

[justmental]

sandergar schreef op 28 March 2003 @ 18:51:
Ben wel beniewd naar de query ... hoe gaat deze er dan ongeveer uitzien?

http://www.jlcomp.demon.co.uk/faq/connectby.html

[momania]

sandergar schreef op 28 March 2003 @ 18:41:
10 niveaus dan 10 tabellen? En wat nu als er een aantal childs opeens verhuisd moeten worden onder een andere parent die zich op een ander niveau bevindt?

Het kan ook wel zoals hij dat wil (en in sommige gevallen is dat ook de betere), maar gezien de data die hij in de database kwijt wil, kan hij het beter met losse tabellen doen.
Ik zie alleen de volgende gegevens:
- Auto merken
- Auto onderdelen
- Onderdeel materialen
- en misschien nog 1 niveau dieper.

Het is natuurlijk aan de TS zelf wat hij met zijn database wil, maar ik wil alleen maar even zeggen dat je bij een database niet alleen moet nadenken over wat je wilt opslaan, maar zeker ook hoe.

Niet echt ... Gebruik 1 SQL opdracht en sla het resultaat op in een recordset! Loop deze structuur door om je recursieve boom op te bouwen!

Wordt er 1 tabel gebruikt dan is dit nog wel de beste oplossing voor de TS; zeker beter als allemaal losse queries afschieten.

[Scharnout]

Zoek eens op RS.GetRows() oftwel [naam van je recordset].GetRows(). Die dumpt alles in een array en die kan je dan doorlopen. Op www.4guysfromrolla.com staan hele mooie ende simpele voorbeelden.