Query Fout, leeg result
Heb ik de volgende functie voor gebouwd, maar hij werkt niet 100%
Functie:
Code (php)
1
2
3
4
5
6
7
2
3
4
5
6
7
<?php //Hier niet opletten, is alleen voor de kleur
Function getLastReg(){
$q = "SELECT LAST(username) FROM users";
$res = mysql_query($q, $this->connection) OR die(mysql_error ());
return $res;
}
?>
Function getLastReg(){
$q = "SELECT LAST(username) FROM users";
$res = mysql_query($q, $this->connection) OR die(mysql_error ());
return $res;
}
?>
Hij geeft een leeg result aan.
Gewijzigd op 01/01/1970 01:00:00 door Stefan Candan
mysql_fetch_assoc()...
ps. Of heb je dat soms in een ander deel van je script staan?
pps. Overigens zal die query ook niet het juiste resultaat opleveren. Het selecteren van de laatst geregistreerde gebruiker doe je door aflopend te sorteren op het tijdstip van registratie en dan het eerste record te selecteren:
Je vergeet dan ook om het resultaat te fetchen met bijvoorbeeld ps. Of heb je dat soms in een ander deel van je script staan?
pps. Overigens zal die query ook niet het juiste resultaat opleveren. Het selecteren van de laatst geregistreerde gebruiker doe je door aflopend te sorteren op het tijdstip van registratie en dan het eerste record te selecteren:
Gewijzigd op 01/01/1970 01:00:00 door Joren de Wit
En dankje over dat fetchen, was ik namelijk helemaal vergete :D
Quote:
En wat is jouw definitie van 'laatste record'. Ga maar eens een backup terug zetten, het laatste record zal dan ineens niet meer de laatst geregistreerde gebruiker bevatten.op de laaste record
De enige juiste manier om de laatst geregistreerde gebruiker te selecteren is het sorteren op tijdstip van registratie. Dat is de enige methode die je zekerheid over je resultaten geeft...
Gewijzigd op 01/01/1970 01:00:00 door yorick17
Quote:
DESC => Descending == Aflopend.DESC (oplopend)
Oftewel, het record met de laatste registratiedatum zal het eerst in de resultaat set zitten. Als je dan met LIMIT de resultaatset beperkt tot 1 record, heb je per definitie het laatste record...
LIMIT hoeft niet eens
yorick17 schreef op 01.01.2009 17:22:
Zekerheid! Zonder LIMIT haal je alle records op en moet je in PHP nog maar zien dat je het juiste record gebruikt. Selecteer je één enkel record, dan heb je in PHP ook meer 1 record om mee te werken.LIMIT hoeft niet eens
Het verkleint de kans op bugs in je script en versnelt bovendien de query omdat er maar 1 record geselecteerd hoeft te worden. Wat is immers het nut om mogelijk een paar miljoen records op te halen als je er maar 1 nodig hebt?
Kortom, gebruik die LIMIT gewoon...
Blanche schreef op 01.01.2009 17:28:
en versnelt bovendien de query omdat er maar 1 record geselecteerd hoeft te worden.
Zeg nu zelf, een query duurt vaak niet langer dan 0,1 sec.
Gewijzigd op 01/01/1970 01:00:00 door yorick17
En bovendien, waarom 0,1 seconde wachten als het ook in 0,01 seconde kan? Een overdreven voorbeeldje: Voer 100 van dat soort queries uit en je hebt een script dat al 10 seconden de tijd nodig heeft om met de database te praten terwijl je het ook in 1 seconde af had kunnen handelen.
Je moet hier absoluut LIMIT gebruiken. Zonder LIMIT selecteer je een hele lijst met records en dat is volledig nutteloos. Een gemiddelde website die enigszins goed loopt heeft tienduizenden of honderdduizenden records in een tabel en dan moet je echt nooit een query zonder LIMIT doen.
Quote:
En dat is maar 1 user en dus hoef je nooit meer dan 1 record op te vragen.Nou, ik wil graag de laast geregistreerde user op mijn index laten zien.
Quote:
Daar valt helemaal niets algemeens over te zeggen, je hebt die records nodig die je wilt en kunt verwerken. 100.000 records waar vrijwel niets in staat, stelt niets voor, 100 records met 1GB aan data in deze records, dat stelt een hele berg voor. Aantallen zeggen niet zo heel erg veel, doe daar dan ook geen algemene uitspraken over.Een gemiddelde website die enigszins goed loopt heeft tienduizenden of honderdduizenden records in een tabel en dan moet je echt nooit een query zonder LIMIT doen.
pgFrank schreef op 01.01.2009 20:14:
100.000 records waar vrijwel niets in staat, stelt niets voor, 100 records met 1GB aan data in deze records, dat stelt een hele berg voor.
pgFrank schreef op 05.12.2008 23:07:
1 GB is een kleine database, dat stelt niet zo heel veel voor.
Ik heb een colom gemaakt genaamd: ID, en auto increment gedaan
Dus de nieuwste record zal het hoogste cijfer hebbe.
Toen heb de functie zodanig aan gepast:
En nu werkt het. Bedankt voor de replies.
Stefan schreef op 01.01.2009 22:04:
Ik heb een colom gemaakt genaamd: ID, en auto increment gedaan
Dus de nieuwste record zal het hoogste cijfer hebbe.
Dus de nieuwste record zal het hoogste cijfer hebbe.
Nee hoor. Je kunt maar 1 ding over een ID zeggen en dat is dat het uniek is. Verder kun je er helemaal niks over zeggen.
De enige manier om dus het nieuwste lid op te vragen is door de registratie datum en tijd op te slaan.
Blanche heeft de juist oplossing allang gegeven
the column naam is ID, en type = int. auto_increment dr op werkt perfect.
Stefan schreef op 02.01.2009 00:09:
Ik ga niet de registratie datum en tijd opslaan, omdat ik 25 mensen niet opnieuw wil laten registreren.
the column naam is ID, en type = int. auto_increment dr op werkt perfect.
the column naam is ID, en type = int. auto_increment dr op werkt perfect.
Nu nog wel ja, wacht maar af
PHP Newbie schreef op 01.01.2009 21:19:
pgFrank schreef op 01.01.2009 20:14:
100.000 records waar vrijwel niets in staat, stelt niets voor, 100 records met 1GB aan data in deze records, dat stelt een hele berg voor.
pgFrank schreef op 05.12.2008 23:07:
1 GB is een kleine database, dat stelt niet zo heel veel voor.
;)
"database" en "record" zijn 2 verschillende dingen... En over het algemeen staan in er in 1 database meerdere records. En wanneer je dan per record 1 GB aan data hebt, kan het vrij snel oplopen. 100 records per iedere 1 GB aan data levert al 100GB aan data op. 1 query die even deze 100 records ophaalt, zal al vrij snel problemen opleveren, ik heb bv. even geen 100GB aan RAM ter beschikking. Dat wordt dus swappen, een goede performance kun je dan wel vergeten.
In huis-tuin-en-keuken applicaties zul je niet snel records van 1GB hebben, dat scheelt dan weer.
Complete films etc ga je toch ook niet opslaan in database, maar een href naar het bestand?
Wanneer je de opname alleen ergens wilt gaan tonen, dan is opslaan van het pad de beste aanpak.