[PHP] rijen categoriseren in groepen *

[link0007]

Voor mijn nieuwe site, een site waar mensen bestanden kunnen uploaden en delen, wil ik een functie hebben voor verschillende categorieën.

In de index.php moet de gebruiker een lijst zoals dit zien:

------------------------------------------
eerste groep
-----------------------------------------
*bestand 1
*bestand 2
*bestand 3
*bestand 4
*bestand 5
------------------------------------------
tweede groep
-----------------------------------------
*bestand 6
*bestand 7
*bestand 8
*bestand 9
*bestand 10

Bestanden staan met veel colommen in de database, met bijvoorbeeld scene_group, scene_id en scene_title

Bij bestand 1-5 staat dus in de database dat scene_group 1 is.
Bij bestand 6-10 staat scene_group = 2

De groepen zelf staan in een aparte tabel, met bijvoorbeeld group_id, group_title


Nu is de vraag: Hoe vraag je informatie op vanuit de database zodat je het met php gemakkelijk uit kan schrijven in verschillende groepen?

Ik wil er een vast aantal queries tegenaan gooien, dus niet iets dat per groep de scenes ophaalt ofzo, dat is niet de bedoeling. Ook moet ik erin kunnen zoeken en sorteren.

ik kan er niks over vinden op internet, en kom op mezelf niet zo snel op een antwoord.

Een methode die ik zelf in gedachten had: Ik sorteer alles eerst op scene_group, dan zet ik de resultset via een loop in een multidimensionale array, met de volgende structuur:

code:

array (
"eerste groep" => array (
                   "bestand 1",
                   "bestand 2",
                   "bestand 3",
                   "bestand 4",
                   "bestand 5"
                   ),
"tweede groep" => array (
                   "bestand 6",
                   "bestand 7",
                   "bestand 8",
                   "bestand 9",
                   "bestand 10"
                   )
)

Met dan de uiteindelijke bestanden in de array ook nog eens een array met informatie over het bestand.

Zijn er nettere oplossingen voor zoiets?

[RobIII]

code:

Select mygroups.groupid, mygroups.groupname, myitems.itemid, myitems.itemname
From mygroups
Inner join myitems om myitems.groupid = mygroups.id
Order by mygroups.groupname, mygroups.groupid, myitems.itemname

code:

CurGroup = -1
For each row in result {
  If CurGroup <> row.groupid {
    print "================"
    print "<b>Groep: " + row.groupname + "</b>"
    print "================"
    CurGroup = row.groupid
  }
  print row.itemname
}

[ Voor 23% gewijzigd door RobIII op 03-09-2008 20:21 ]

[MSalters]

't Lijkt me eerlijk gezegd wel zo slim om eerst groep1 op te halen. Die kun je alvast formatteren en richting de browser sturen terwijl je werkt aan groep 2. Nu begin je pas met het verzenden van HTML nadat je alle data hebt opgehaald.

[RobIII]

MSalters schreef op woensdag 03 september 2008 @ 23:36:
't Lijkt me eerlijk gezegd wel zo slim om eerst groep1 op te halen.

Ik haal in 1 query alle groepen + items op (even er van uit gaande dat dat er geen duizenden zijn natuurlijk en dat je ze ALLEMAAL wil outputten.. anders even een WHERE clause er op hangen )

MSalters schreef op woensdag 03 september 2008 @ 23:36:
Nu begin je pas met het verzenden van HTML nadat je alle data hebt opgehaald.

Euh, nee? Iedere (pseudo)print kan meteen naar de browser.

[ Voor 13% gewijzigd door RobIII op 04-09-2008 00:24 ]

[Gomez12]

MSalters schreef op woensdag 03 september 2008 @ 23:36:
't Lijkt me eerlijk gezegd wel zo slim om eerst groep1 op te halen. Die kun je alvast formatteren en richting de browser sturen terwijl je werkt aan groep 2. Nu begin je pas met het verzenden van HTML nadat je alle data hebt opgehaald.

Werkt dit echt bevorderend bij een redelijke website?

Lijkt mij opzich alleen van toepassing als je heel langzame query's hebt. En al helemaal niet bij groepjes in groottes van 5 / 10, lijkt me dat je dan veels te veel query's gaat creeeren tegen veels te weinig winst.
( stiekem gebruik ik het principe wel eens om in een ajax app alvast de 1e helft vd resultaten met php te genereren voor in de html en de 2e helft via ajax erbij te zoeken, maar dan loopt de paging etc ook allemaal via ajax )

Lijkt mij een theoretische micro-optimalisatie bij het genoemde voorbeeld wat praktisch imho alleen maar betekent dat je dbase geen goede caching kan opbouwen, je risico hebt op te veel query's op je dbase bij een redelijk aantal gelijktijdige gebruikers en dat je een zooi onnodig verkeer genereert tussen webserver en dbase server zolang je het over kleine rechtlijnige result-sets hebt.
Maar als ik dit fout zie zou ik het gaarne weten, want het concept staat me wel aan...

RobIII schreef op donderdag 04 september 2008 @ 00:09:
[...]

Euh, nee? Iedere (pseudo)print kan meteen naar de browser.

Maar je (pseudo) prints kunnen pas beginnen als je dbase server alle resultaten verstuurd heeft naar PHP.
Doet je dbase server er 1 minuut over om alle resultaten aan php af te geven dan kan ik MSalters argument wel begrijpen, bij normale tijden lijkt deze aanpak mij alleen maar negatief.

Of tenminste, ik vermoed dat MSalters dit bedoelde...

[ Voor 16% gewijzigd door Gomez12 op 04-09-2008 00:19 ]

[RobIII]

Gomez12 schreef op donderdag 04 september 2008 @ 00:15:
Maar je (pseudo) prints kunnen pas beginnen als je dbase server alle resultaten verstuurd heeft naar PHP.
Doet je dbase server er 1 minuut over om alle resultaten aan php af te geven dan kan ik MSalters argument wel begrijpen, bij normale tijden lijkt deze aanpak mij alleen maar negatief.

Of tenminste, ik vermoed dat MSalters dit bedoelde...

Allereerst: wie zegt dat het over PHP gaat En waarom zou alles al "verstuurd" moeten worden door de DB voor je kunt beginnen met outputten (of is dat in PHP zo?) ? En als het toch al een minuut zou duren, dan maak je het niet sneller door in kleine brokken te hakken; dat levert alleen maar meer overhead en dus nog langzamer. Enige voordeel zou dan zijn, als "PHP" zou moeten wachten dat je idd al eerder kan gaan outputten; de hele pagina duurt dan echter langer. In zo'n geval zou ik sowieso eens gaan kijken waarom je zoveel naar de browser stuurt.

Ik ga er van uit dat de data in de TS (paar groepjes van 5 items) wel overeenkomt met de daadwerkelijke situatie ja, en in zo'n geval boeit het dus, linksom of rechtsom, toch niet Dus tot een paar tiental items en ditto groepen zal het geen probleem zijn, praat je over duizenden dan wordt het andere koek.

[ Voor 12% gewijzigd door RobIII op 04-09-2008 00:31 ]

[.oisyn]

PHP doet idd vrij weinig aan asynchrone processing

[Gomez12]

RobIII schreef op donderdag 04 september 2008 @ 00:27:
[...]
Allereerst: wie zegt dat het over PHP gaat

Niemand behalve ik.

En waarom zou alles al "verstuurd" moeten worden door de DB voor je kunt beginnen met outputten (of is dat in PHP zo?) ?

Hoeft niet, maar praktisch gezien kan ik zo snel geen grote dbase bedenken die aggegrated functies ondersteunt en dit niet doet? Verstuurd is misschien het verkeerde woord, intern het totaal opgehaald is beter verwoord.

En als het toch al een minuut zou duren, dan maak je het niet sneller door in kleine brokken te hakken; dat levert alleen maar meer overhead en dus nog langzamer.

Totaal langzamer, maar voor de gebruiker komt het toch sneller en plezieriger over als hij na 1 sec al iets te zien heeft ipv eerst 1 minuut te moeten wachten, ook al duurt het totaal ophalen van 120 rijen dan opeens 2 minuten ipv 1 minuut voor het totaal. ( praktisch voorbeeld, dbase met 120.000 artikelen die totaal niet performde (reden daarvoor is net weer niet boeiend), totale 120.000 artikelen ophalen voor een listview kostte serieus 5 minuten. Klant wilde bij artikelselectie een listview gevuld zien zodat hij kon scrollen en bovenin een aantal zoekvenstertjes waarmee hij zijn zoekactie kon verfijnen, toen was er dus ook gekozen voor ophalen per 100. Et voila, we hadden een redelijk performende app zolang niemand wild werd met het scrollwieltje )

Ik ga er van uit dat de data in de TS (paar groepjes van 5 items) wel overeenkomt met de daadwerkelijke situatie ja, en in zo'n geval boeit het dus, linksom of rechtsom, toch niet

In zo'n geval boeit het imho juist wel, je overhead gaat volgens mij zo groot worden dat het voor de gebruiker gewoon trager gaat aanvoelen ipv sneller... Je resultset wordt te klein...

[Verwijderd]

Waarschijnlijk word mysql_unbuffered_query bedoelt. Verder lijkt mij de oplossing van Rob het meest wenselijk.

[RobIII]

Gomez12 schreef op donderdag 04 september 2008 @ 01:12:
Totaal langzamer...<snip>... met het scrollwieltje

Uiteraard; voor de user experience is het beter.

Gomez12 schreef op donderdag 04 september 2008 @ 01:12:
In zo'n geval boeit het imho juist wel, je overhead gaat volgens mij zo groot worden dat het voor de gebruiker gewoon trager gaat aanvoelen ipv sneller... Je resultset wordt te klein...

Ja, uiteraard, ik doelde dan ook niet zo zeer op het wel/niet boeien van de 'meerdere queries methode' maar op het niet boeien of je een array'tje maakt of mijn methode gebruikt of whatever.

Verwijderd schreef op donderdag 04 september 2008 @ 01:14:
Waarschijnlijk word mysql_unbuffered_query bedoelt.

Maar zolang nog niet vast staat dat het over PHP gaat in dit topic....

[ Voor 17% gewijzigd door RobIII op 04-09-2008 01:29 ]

[Verwijderd]

Het lijkt me toch wel dat het over PHP gaat, aangezien de topic starter het over zijn pagina index.php heeft.
Om iets anders dan PHP in zijn pagina te schrijven zou toch een beetje vreemd zijn

[RobIII]

Verwijderd schreef op donderdag 04 september 2008 @ 07:42:
Het lijkt me toch wel dat het over PHP gaat, aangezien de topic starter het over zijn pagina index.php heeft.

Scherp Da's dan ook de enige clue. Ik zal 't even in de topictitel zetten...

[ Voor 7% gewijzigd door RobIII op 04-09-2008 08:49 ]