Query Fout, leeg result
Nou, ik wil graag de laast geregistreerde user op mijn index laten zien.
Heb ik de volgende functie voor gebouwd, maar hij werkt niet 100%
Functie:
Hij geeft een leeg result aan.
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
Je vergeet dan ook om het resultaat te fetchen met bijvoorbeeld 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:
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
Blanche, mijn script zet automatisch de laast geregistreerde user op de laaste record. dus SELECT LAST zal wel werken.
En dankje over dat fetchen, was ik namelijk helemaal vergete :D
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...
Dus hier komt uit dat je op de registreerdatum moet filteren. En als je dan met DESC (aflopend) in je sql een query draait en het laatste resultaat oppakt heb je dus de laatst geregistreerde gebruiker
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:
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:
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
Oh ja? En over hoeveel records hebben we het dan?
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.
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:
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:
1 GB is een kleine database, dat stelt niet zo heel veel voor.
Het is opgelost, en Frank, de website is voor een clan, dus het zal hoogstens 30 tot 50 records hebben.
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.
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:
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
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.
'Stefan:
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:
'pgFrank:
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:
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.
Ik wil al zeggen: wat voor data (dat in een database moet) is nu 1 gb?
Complete films etc ga je toch ook niet opslaan in database, maar een href naar het bestand?
Complete films etc ga je toch ook niet opslaan in database, maar een href naar het bestand?
@Eddy: Ligt volledig aan de toepassing, het kan heel handig zijn om complete opnames (film of foto) in de database op te slaan, je kunt dan de database allerlei vergelijkingen e.d. laten doen. Zo zijn voor PostgreSQL toepassingen gebouwd die röntgenfoto's en MRI-scans met elkaar vergelijken. Door deze vergelijkingen binnen de database te toen (met stored procedures in Java of C) kun je dan nog een hele behoorlijke performance behalen. Wanneer je vergelijkingen moet doen op data, zul je de data wel tot je beschikking moeten hebben en moet het dus in de database staan.
Wanneer je de opname alleen ergens wilt gaan tonen, dan is opslaan van het pad de beste aanpak.
Wanneer je de opname alleen ergens wilt gaan tonen, dan is opslaan van het pad de beste aanpak.




