OOhhhh die is goed die tipquote:Op donderdag 10 mei 2007 15:56 schreef CraZaay het volgende:
En een extragatis tip: leg tussen het 'venster' en de rest van de content een viewport-vullende div met een (semi-)transparante achtergrond als je niet wilt dat bezoekers buiten dat 'venster' op een link kunnen klikken.
Die is behoorlijk brak. Als je scrolt gaat het al misquote:
LOL je hebt gelijkquote:Op donderdag 10 mei 2007 16:00 schreef SuperRembo het volgende:
[..]
Die is behoorlijk brak. Als je scrolt gaat het al mis
Onder Safari gaat het scrollen wel goed, het is alleen jammer dat hij linksboven aan het venster snapt, en hij alle tekst op de pagina selecteert.quote:Op donderdag 10 mei 2007 16:00 schreef SuperRembo het volgende:
[..]
Die is behoorlijk brak. Als je scrolt gaat het al mis
Daarnaast gaat het bewegen fout, het maximaliseren is ruk en staat er levensgroot "deprecated" boven. Laat staan dat het er in m'n linuxdistro ontzettend lelijk uit zietquote:Op donderdag 10 mei 2007 16:00 schreef SuperRembo het volgende:
[..]
Die is behoorlijk brak. Als je scrolt gaat het al mis
Hebben jullie misschien een idee wat dat kan zijn? Indien ik de pagina niet include dan doet deze het wel. Zie hier.quote:Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
Zie voor meer info dus [PHP&MySQL] Includen en "correct" uitlezen uit de databasequote:Op donderdag 10 mei 2007 17:09 schreef poepeneesje het volgende:
Ik krijg de volgende error als ik probeer een pagina met daarin data uit een MsyQL-database probeer te includen:
Waarschijnlijk gebruik je ergens identieke variabellen-namen in de verschillende bestanden?quote:Op donderdag 10 mei 2007 17:09 schreef poepeneesje het volgende:
Beste mede-fokkers,
Ik krijg de volgende error als ik probeer een pagina met daarin data uit een MsyQL-database probeer te includen:
[..]
Hebben jullie misschien een idee wat dat kan zijn? Indien ik de pagina niet include dan doet deze het wel. Zie hier.
Poepeneesje.
Zou je zeggen ja!.quote:Op woensdag 9 mei 2007 12:39 schreef JeRa het volgende:
@Chandler
Het enige wat ik nu even kan bedenken is dat hij COUNT(weblog_posts.id) als een aggregaatfunctie ziet bij "GROUP BY weblog_posts.id", waardoor hij het aantal weblog_posts.id's pér weblog_posts.id gaat tellen. Dan zou je als het goed is een hoop records met '1' moeten terugkrijgen. Zoek je niet toevallig COUNT(*)?
Ik zal wel moeten, dit omdat ik 2 queries draai.quote:Op woensdag 9 mei 2007 13:38 schreef JortK het volgende:
Ja als hij het aantal records wil weten wel ja :Y
Het is trouwens nooit aan te raden om een veld wat in een aggregate function staat ook in een groupy by te gebruiken.
1 |
Huh?quote:Op donderdag 10 mei 2007 17:57 schreef Chandler het volgende:
[..]
group by is namelijk een vereiste bij joins..![]()
PHP komt met een interpreter die je vanaf de command-line kunt aanroepen met een PHP file als argument. Bijvoorbeeld onder DOS:quote:Op donderdag 10 mei 2007 19:06 schreef Geqxon het volgende:
Bestaat er voor bijvoorbeeld Mac OS X een PHP compiler? Dat ik in de terminal gewoon PHP commands (of desnoods een lap code) in kan voeren, en hij het resultaat teruggeeft?
Zou voor sommige kleine testpunten wel makkelijk zijn
1 |
@jera; dat doe je normaal toch met MySQL_NUM_ROWS... maar dan is de query al in zijn geheel uitgevoerd... en dat wil ik dus voorkomen qua preformance.quote:Op donderdag 10 mei 2007 18:53 schreef JeRa het volgende:
@Chandler
Het is nog steeds niet duidelijk wat je precies wilt tellen; het aantal mogelijke resultaten kun je eventueel afleiden door SQL_CALC_FOUND_ROWS en FOUND_ROWS() te gebruiken, het aantal resultaten per pagina bepaal je enerzijds vantevoren en anderzijds door te kijken hoeveel records je terugkrijgt.
@SuperRembo
Hij bedoelt dat hij een GROUP BY moet plaatsen omdat ie anders één item meerdere keren als zoekresultaat terugkrijgt
1 2 3 4 5 6 | FROM weblog_posts LEFT JOIN users ON users.id = weblog_posts.user_id LEFT JOIN weblog ON weblog.id = weblog_posts.weblog_id WHERE weblog_posts.subject LIKE '%post%' GROUP BY weblog_posts.id |
1 2 3 4 5 6 | FROM weblog_posts LEFT JOIN users ON users.id = weblog_posts.user_id LEFT JOIN weblog ON weblog.id = weblog_posts.weblog_id WHERE weblog_posts.subject LIKE '%post%' GROUP BY weblog_posts.id |
Ook niet...quote:Op donderdag 10 mei 2007 17:41 schreef Tuvai.net het volgende:
[..]
Waarschijnlijk gebruik je ergens identieke variabellen-namen in de verschillende bestanden?
1 |
1 2 3 4 5 6 | FROM weblog_posts wp JOIN users u ON u.id=wp.user_id JOIN weblog w ON w.id=wp.weblog_id WHERE wp.subject LIKE '%post%' ORDER BY wp.id |
Als jij een COUNT(*) doet moet MySQL toch de hele query uitvoeren, dus qua performance zit je niet goed. Sterker nog, je moet echt eens kijken naar SQL_CALC_FOUND_ROWS, omdat je daarmee óók met een LIMIT-clausule het totaal aantal rijen kunt bepalen, en je dus maar één query hoeft uit te voerenquote:Op donderdag 10 mei 2007 19:16 schreef Chandler het volgende:
[..]
@jera; dat doe je normaal toch met MySQL_NUM_ROWS... maar dan is de query al in zijn geheel uitgevoerd... en dat wil ik dus voorkomen qua preformance.
"De eerste resultaten"? En je weet dat een COUNT() zonder LIMIT alsnog de hele query uitvoert?quote:Op donderdag 10 mei 2007 19:47 schreef Chandler het volgende:
Helaas zit je toch FOUT!hehe
Stel een gebruiker wil het volgende.
1. Kijken hoeveel postings het woord (post) hebben.
2. Kijken hoeveel reacties een gebruiker heeft gepost (op basis van inner join met 'users')
3. Kijken hoeveel reacties een IP adres heeft en ga zo maar door.
Daarom moet ik de eerste resultaten doro een count halen. Daarna kan ik deze per pagina laten oproepen... Of zit ik nou raar te spacen?
Alleen als die velden daadwerkelijk opgehaald worden. Als je SQL_CALC_FOUND_ROWS gebruikt, wordt jouw tweede query uitgevoerd en zodra de LIMIT bereikt is gaat ie verder joinen (zonder de waarden op te halen!) en doet ie in feite een COUNT(*). Reken daarbij dat je maar de overhead van één grote en één kleine query hebt t.o.v. één grote en één normale query en je hebt performancewinst.quote:Op donderdag 10 mei 2007 21:45 schreef Chandler het volgende:
Dat weet ik, maar als je een query uitvoert op alle velden van een tabel of alleen op de ID's van een tabel scheelt dit toch aardig in de preformance?
"query uitvoeren op"? Het verschil zit 'm toch enkel in de hoeveelheid data die je retourneert? de where-claus blijft hetzelfde, net als de joins, etc.quote:Op donderdag 10 mei 2007 21:45 schreef Chandler het volgende:
Dat weet ik, maar als je een query uitvoert op alle velden van een tabel of alleen op de ID's van een tabel scheelt dit toch aardig in de preformance?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | <tr> <td>titel 1</td> <td>titel 2</td> </tr> <tr> <td>titel 1</td> <td>titel 2</td> </tr> <tr> <td>titel 1</td> <td>titel 2</td> </tr> <tr> <td>titel 3</td> <td>titel 4</td> </tr> </table> |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | while($Details03 = mysql_fetch_assoc($result_detail03)) { if($kolom < 2) { if($kolom == 0) {$tabel .= "\r\t<tr>";} if($Details03['title_language'] != '') { $tabel .= "\r\t\t<td>".$Details03['title']."(".$Details03['title_language'].")</td>"; } else { $tabel .= "\r\t\t<td>".$Details03['title']."</td>"; } $kolom++; } else { $tabel .= "\r\t</tr>"; $kolom = 0; } } $tabel .= "\r\t</tr>"; ?> |
Forum Opties | |
---|---|
Forumhop: | |
Hop naar: |