Heb je een auto-increment veld in de database (dit is trouwens niet echt een fantastische naam) tabel? Dan is dit simpelweg een kwestie van deze kolom toevoegen:
ORDER BY id DESC, leerling, datum
ASC is meestal de default, dus die kun je eventueel weglaten, of je doet het explicieter:
ORDER BY id DESC, leerling ASC, datum ASC
Dat zorgt ervoor dat er eerst (aflopend) op id wordt gesorteerd, wat ervoor zorgt dat je de laatste 30 records kunt selecteren. Dan oplopend op leerling (wat dit ook moge betekenen? een naam? een leerlingnummer?) en tot slot op datum.
EDIT, of als het argument de datum is: zet de datum vooraan, zodat hier éérst aflopend op wordt gesorteerd.
sql = "
SELECT * FROM database
WHERE user = '".$_SESSION['user']."'
AND klaar = '1'
ORDER BY datum DESC
LIMIT 0,30";
Dat dan weer sorteren:
SELECT * FROM (
SELECT * FROM database
WHERE user = '".$_SESSION['user']."'
AND klaar = '1'
ORDER BY datum DESC
LIMIT 0,30
) x
ORDER BY leerling, datum ASC";
Die "x" staat er omdat elke "afgeleide tabel" een alias moet hebben.
Een tabel is geen database, maar een onderdeel van een database. Zie het hier als een entiteit van iets.
In jouw geval haal je dus personen op, dus zou users, participants of members een betere naam voor de tabel zijn. Het ligt ook een beetje aan wat voor applicatie je maakt, en wat voor personen je opslaat. Als deze onder te verdelen zijn in twee of meerdere soorten (gebruikers, beheerder) dan is users een pakkende naam die beide partijen dekt.
Het idee is nu dat je datum technisch de laatste 30 pakt, maar daarna deze hele set van 30 sorteert op `leerling` (geen idee waarom; en dan nogmaals `datum`).
Dit:
ORDER BY datum DESC, leerling, datum ASC
LIMIT 0,30
gaat niet werken.
Stel dat de laatste entries allemaal op een opvolgende dag in juni zijn gemaakt (dus 1 juni, 2 juni, enz - t/m 30 juni). Door de eerste sortering staan dan de records op datum volgorde (30 juni, 29 juni, ... 1 juni). Dan heeft het daarna geen zin meer om op leerling (en al helemaal niet nogmaals op datum) te sorteren, omdat die eerste sorting de boel al helemaal vast heeft gelegd. Het resultaat is dan niet zoals gewenst.
Als het anders/beter kan hoor ik het graag. Dit is zoals ik het zou doen.
Alhoewel ik het eigenlijk misschien anders zou doen: Ik zou alleen de eerste query door de database laten doen (de laatste 30 bepalen; er ook vanuit gaande dat er een index op de `datum` zit), en de sortering binnen die set van (slechts) 30 stuks gewoon even in PHP doen. Door die "afgeleide tabel" gaat MySQL voor die laatste sortering waarschijnlijk met temporary table + filesort lopen hannesen, en dat is een beetje jammer als het om slechts 30 stuks gaat. Door dit zelf te doen kan MySQL je gewoon een direct antwoord geven op basis van de index (= geen gehannes).
Je hebt gelijk, zit vandaag in een dipje denk ik :].
Het is wss wel handig als de topicstarter wat opheldering geeft hoe de tabel er precies uitziet, en wat voor betekenis de kolommen hebben. Dat helpt ons allemaal om een makkelijke(re) oplossing te verzinnen.
